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About This Guide 


Novell® Certificate Server™ provides public key cryptography services that are natively 
integrated into eDirectory® and that allow you to mint, issue, and manage both user and server 
certificates. These services allow you to protect confidential data transmissions over public 
communications channels such as the Internet. 


This guide describes the functionality of Novell Certificate Server, how to set it up, and how to 
manage it. This book also provides some basic information about how public key cryptography 
works. 


+ Chapter 1, “Overview,” on page 11 

+ Chapter 2, “Setting Up Novell Certificate Server,” on page 17 

+ Chapter 3, “Managing Novell Certificate Server,” on page 23 

+ Chapter 4, “Troubleshooting,” on page 53 

+ Appendix A, “Public Key Cryptography Basics,” on page 61 

+ Appendix B, “Entry Rights Needed to Perform Tasks,” on page 67 


Documentation Updates 


For the most recent version of the Novell Certificate Server 2.7 Administration Guide, see the 
Novell Certificate Server Web site (http://www.novell.com/documentation/lg/crt27/index.html). 


Documentation Conventions 


In this documentation, a greater-than symbol (>) is used to separate actions within a step and items 
in a cross-reference path. 


A trademark symbol @, TM, etc.) denotes a Novell trademark. An asterisk (*) denotes a third-party 
trademark. 
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Overview 


Novell® Certificate Server™ provides public key cryptography services that are natively 
integrated into Novell eDirectory® and that allow you to mint, issue, and manage both user and 
server certificates. These services allow you to protect confidential data transmissions over public 
communications channels such as the Internet. 


NOTE: If you are unfamiliar with public key cryptography concepts, see “Public Key Cryptography Basics” on 
page 61. 


Public key cryptography presents unique challenges to network administrators. Novell Certificate 
Server helps you meet these challenges in the following ways: 


+ 


Provides public key cryptography services on your network 


You can create an Organizational Certificate Authority (CA) within your eDirectory tree, 
allowing you to issue an unlimited number of user and server certificates. You can also use 
the services of an external certificate authority, or use a combination of both as your needs 
dictate. 


Controls the costs associated with obtaining and managing public key certificates 


You can create an Organizational CA and issue public key certificates through the 
Organizational CA. 


Allows public key certificates to be openly available while also protecting them against 
tampering 


Certificates are stored in eDirectory and can therefore leverage eDirectory replication and 
access control features. 


Allows private keys to be accessible to only the software routines that use them for signing 
and decrypting operations 


Private keys are encrypted by Novell International Crvtographv Infrastructure (NICI) and 
made available only to the software routines using them for signing and decrypting 
operations. 


Securely backs up private keys 


Private keys are encrypted by NICI, stored in eDirectorv, and backed up using standard 
eDirectory backup utilities. 


Allows central administration of certificates using Novell iManager®. You can also perform 
some administration tasks using ConsoleOne. 


Allows users to manage their own certificates 


Users can use iManager to export keys for use in cryptography-enabled applications without 
system administrator intervention. 


Supports popular e-mail clients and browsers 


Novell Certificate Server allows you to create and manage user certificates for securing e- 
mail. Novell Certificate Server supports Group Wise® 5.5 or later, Microsoft* Outlook 98 and 
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Outlook 2000, Netscape* Messenger*, and other popular e-mail clients. It's also compatible 
with both Netscape Navigator* and Microsoft Internet Explorer. 


Product Components 


Novell Certificate Server 
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Novell Certificate Server consists of the PKI server component, a plug-in module to Novell 
iManager, and a snap-in module to ConsoleOne. Novell iManager and ConsoleOne are the 
administration points for Novell Certificate Server. 


Novell Certificate Server allows you to request, manage, and store public key certificates and their 
associated key pairs in the eDirectory tree, and to establish an Organizational certificate authority 
that is specific to your eDirectory tree and your organization. 


Novell Certificate Server derives all supported cryptography and signature algorithms, as well as 
supported key sizes, from Novell International Cryptographic Infrastructure (NICT). Therefore, a 
single version of Novell Certificate Server can be used in installations throughout the world. 


After installing Novell Certificate Server, you will manage it using: 
+ Novell iManager. 


+ ConsoleOne running on a client. (Novell Certificate Server cannot be managed using 
ConsoleOne running on a NetWare server console.) 


Through ConsoleOne and Novell iManager, you can perform the following tasks: 
+ Create an Organizational certificate authority for your organization 


During the installation, you can elect to create an Organizational Certificate Authority (CA) 
if one does not already exist in the eDirectorv tree. You can also create or re-create the 
Organizational CA after the installation is completed. 


The Organizational CA object contains the public key, private key, certificate, certificate 
chain, and other configuration information for the Organizational CA. The Organizational CA 
object resides in the Security container in eDirectory. 


After a server is configured to provide the certificate authority service, it performs that service 
for the entire eDirectory tree. 


+ Create a Server Certificate object for each cryptography-enabled application 


During the installation, you can elect to create a Server Certificate object. You can create other 
Server Certificate objects after the installation is completed. 


The Server Certificate object contains the public key, private key, certificate, and certificate 
chain that enables SSL security services for server applications. Server Certificate objects can 
be created by either the Organizational CA or by an external CA. 


A server can have many Server Certificate objects associated with it. Any cryptography- 
enabled applications running on a particular server can be configured to use any one of the 
Server Certificate objects for that server. Multiple applications running on a given server can 
use the same Server Certificate object; however, a Server Certificate object cannot be shared 
between servers. 


You can create Server Certificate objects only in the container where the server resides. If the 
Server object is moved, all Server Certificate objects belonging to that server must be moved 
as well. You should not rename a Server Certificate object. You can determine which Server 
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Certificate objects belong to a server by searching for the server's name in the Server 
Certificate Object Name or by looking at the host server filed when viewing the Server 
Certificate object in ConsoleOne. 

NOTE: The key pair stored in the Server Certificate object is referenced by the name you enter when the 
key pair is created. The key pair name is not the name of the Server Certificate object. When configuring 


cryptography-enabled applications to use key pairs, you reference those keys by their key pair name, not 
by the Server Certificate object name. 


Create a user certificate 


Users have access to their own user certificates and private keys, which can be used for 
authentication, data encryption/decryption, digital signing, and secure e-mail. One of the most 
common uses is sending and receiving digitally signed and encrypted e-mail using the S/ 
MIME standard. 


Generallv, only the CA administrator has sufficient rights to create user certificates. However, 
only the user has rights to export or download the private key from eDirectory. Any user can 
export any other user's public key certificate. 


The user certificate is created from the Security tab of the user's property page and is signed 
by the Organizational CA. Certificates created by other CAs can only be imported after having 
been created. 


Multiple certificates can be stored on the user's object. 
Create a Trusted Root Container 


A trusted root provides the basis for trust in public key cryptography. Trusted roots are used 
to validate certificates signed bv other CAs. Trusted roots enable securitv for SSL, secure e- 
mail, and certificate-based authentication. 


A Trusted Root Container is an eDirectorv object that contains Trusted Root objects. 
You must create the Trusted Root Container in the Security Container. 
Create a Trusted Root object 


A Trusted Root object is an eDirectory object that contains a CA’s Trusted Root certificate 
that is known to be authentic and valid. The Trusted Root Certificate can be exported and used 
as needed. Applications that are configured to use the Trusted Root Certificate consider a 
certificate valid if it has been signed by one of the CAs in the Trusted Root Container. 


The Trusted Root object must reside in a Trusted Root Container. 
Create certificates for external users and servers 


The CA administrator can use the Organizational CA to sign certificates for users and servers 
that reside in other trees. Such certificates are requested using a Certificate Signing Request 
(CSR) provided to the CA administrator in an out-of-band fashion. 


Given a CSR, the CA administrator can issue the certificate using the Issue Certificate tool in 
ConsoleOne or Novell iManager. The resulting certificate is not stored in an object in 
eDirectory. It must be returned to the requestor in an out-of-band fashion. 


Validate certificates 


Novell Certificate Server allows you to check the validity of any certificate in the eDirectory 
tree. This feature checks each certificate in the certificate chain back to the trusted root 
certificate and returns a status of Valid or Invalid. 
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Certificates are considered valid if they pass a pre-defined set of criteria including whether the 
current time is within the validity period of the certificate, whether it has not been revoked, 
and whether it has been signed by a CA that is trusted. 


When validating user certificates or intermediate CA certificates signed by external CAs, the 
external CA's certificate must be stored in a Trusted Root object in order for the certificate 
validation to be successful. The Trusted Root object must be in a Trusted Root Container 
named Trusted Roots and it must be located in the Security container. 


Export private keys and certificates 


User, server, and CA keys can be marked as exportable when they are created. If a key is 
exportable, it can be extracted and put in a file along with the associated certificate. The file 
is written in an industry standard format (PFX or PKCS #12), which allows it to be transported 
to other platforms. It is encrypted with a user-specified password to protect the private key. 


Exporting private keys and certificates can be done to obtain a backup copy of the key, to 
move the key to a different server, or to share the key between servers. 


Import private keys and certificates 


You can choose to import a key rather than create a new one at the time a Server Certificate 
or a CA object is created. The key and its associated certificates must be in PFX or PKCS #12 
format. 


You might choose to import a key rather than create a new one for a CA object to recover from 
a server failure or to move the Organizational CA from one server to another. 


You might choose to import a key rather than create a new one for a Server Certificate object 
to recover from a server failure, to move the key and certificate to another server, or to share 
the key and certificate with another server. 


Create a SAS service object (Novell iManager) 


The SAS service object facilitates communication between a server and its server certificates. 
If you remove a server from an eDirectory tree, you also need to delete the SAS service object 
associated with that server. Likewise, if you want to put the server back into the tree, you must 
create the SAS service object to go with that server. If you do not, you cannot create new 
server certificates. 


You can create a new SAS service object only if there is not a properly named SAS service 
object in the same container as the server object. For example, for a server named WAKE, you 
will have a SAS service object named SAS Service - WAKE. The utility will add the DS 
pointers from the Server object to the SAS object, and from the SAS object to the Server 
object, as well as set up the correct ACL entries on the SAS service object. 


Ifa SAS service object already exists with the proper name, you cannot create a new one. The 
old SAS service object's DS pointers might be wrong or missing, or the ACLs might not be 
correct. In this case, you can delete the corrupt SAS service object and use ConsoleOne or 
Novell iManager to create a new one. If there are server certificates that belong to this server, 
you need to link them up to the SAS service object manually by using the Other tab from 
ConsoleOne. 


Novell International Cryptographic Infrastructure 
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Novell International Cryptographic Infrastructure (NICI) is the underlying cryptographic 
infrastructure that provides the cryptography for Novell Certificate Server, Novell Modular 
Authentication Services (NMAS'M), and other applications. 
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NICI must be installed on the server in order for Novell Certificate Server to work properly. NICI 
does not ship with Novell Certificate Server. The proper version of NICI might be provided when 
Novell Certificate Server is bundled with another product, such as NetWare or eDirectory, or you 
might need to download a newer version of NICI from Novell's Software Download Web site 
(http://www.novell.com/download). When Novell Certificate Server is bundled with other 
products, you might be required to install NICI manually, or NICI might be automatically 
installed. Refer to the product’s installation guide for more information. 


For Additional Information 


For instructions on installing Novell Certificate Server when it is included with another Novell 
product, see the installation guide for that product. 


For instructions on setting up Novell Certificate Server, see Chapter 2, “Setting Up Novell 
Certificate Server,” on page 17. 


For information about administering Novell Certificate Server, see Chapter 3, “Managing Novell 
Certificate Server,” on page 23. 


For the latest online documentation for this and other Novell products, see the Product 
Documentation Web site (http://www.novell.com/documentation). 


For additional information about this and other Novell security products and technologies, see the 
Novell Security Web site (http://www.novell.com/security). 
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Setting Up Novell Certificate Server 


After you install Novell® Certificate Server™, you must set it up for use on your network by 
completing the following tasks: 


+ “Deciding Which Type of Certificate Authority to Use” on page 17 

+ “Creating an Organizational Certificate Authority Object” on page 18 
+ “Creating Server Certificate Objects” on page 19 

+ “Configuring Cryptography-Enabled Applications” on page 20 


Deciding Which Type of Certificate Authority to Use 


Novell Certificate Server allows you to create certificates for both servers and end users. Server 
Certificates can be signed by either the Organizational CA or by an external or third-party CA. 
User certificates can only be signed by the Organizational CA. 


During the Server Certificate object creation process, you are asked which type of Certificate 
Authority will sign the Server Certificate object. 


The Organizational Certificate Authority is specific to your organization and uses an 
organizational-specific public key for signing operations. The private key is created when you 
create the Organizational Certificate Authority. 


An external Certificate Authority is managed by a third party outside of the eDirectory tree. An 
example of an external Certificate Authority is VeriSign*. 


Both types of Certificate Authorities can be used simultaneously. Using one type of Certificate 
Authority does not preclude the use of the other. 


Benefits of Using an Organizational Certificate Authority Provided with Novell 
Certificate Server 


+ Compatibility. The Organizational Certificate Authority is compatible with Novell 
applications such as LDAP services, Portal Services, and the Novonyx Web Server. 
Certificates issued by the Organizational CA are X.509 v3 compliant and can also be used by 
third-party applications. 


+ Cost savings. The Organizational Certificate Authority lets you create an unlimited number 
of public key certificates at no cost; obtaining a single public key certificate through an 
external Certificate Authority might cost a significant amount of money. 


+ Component of a complete and compatible solution. By using the Organizational Certificate 
Authority, you can use the complete cryptographic system built into Novell eDirectory™ 
without relying on any external services. In addition, Novell Certificate Server is compatible 
with a wide range of Novell products. 
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+ Certificate attribute and content control. An Organizational Certificate Authority is 
managed by the network administrator, who decides on public key certificate attributes such 
as certificate life span, key size, and signature algorithm. 


+ Simplified management. The Organizational Certificate Authority performs a function 
similar to external certificate authorities but without the added cost and complexity. 


Benefits of Using an External Certificate Authority 


+ Liability. An external Certificate Authority might offer some liabilitv protection if, through 
the fault of the Certificate Authoritv, vour private kev was exposed or vour public kev 
certificate was misrepresented. 


+ Availability. An external Certificate Authority’s certificate might be more widely available 
and more widelv trusted bv applications outside of eDirectorv. 


Creating an Organizational Certificate Authoritv Object 


By default, the Novell Certificate Server installation process creates the Organizational Certificate 
Authority (CA) for you. You are prompted to specify an Organizational CA name. When you click 
Finish, the Organizational CA is created with the default parameters and placed in the Securitv 
container. 


If vou want more control over the creation of the Organizational CA, vou can create the 
Organizational CA manually using ConsoleOne® or Novell iManager. Also, if you delete the 
Organizational CA, you will need to re-create it. 


IMPORTANT: During the creation process, you are prompted to name the Organizational Certificate Authority 
object and to choose a server on which the Certificate Authority service will run. 


Select a server that is physically secure, that will be available when needed to perform signing operations, that 
runs a protocol that is compatible with the other servers in your organization (for example, IP, IPXTM, IP/IPX), 
and that only runs software that you trust. It is important that your server meet these conditions, because the 
Organizational Certificate Authority object is the centerpiece of your PKI system and if the server that contains 
the object is compromised, your entire PKI system could be compromised as well. 


To create the Organizational Certificate Authority object using ConsoleOne: 
1 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,' on page 67. 


2 Start ConsoleOne. 

3 Expand the eDirectorv tree where you want to create the Organizational Certificate Authority. 
This reveals the Securitv container object. 

4 Right-click the Security container object, then click New > Object. 

5 From the list box in the New Object dialog box, double-click NDSPKI:Certificate Authority. 


This opens the Create an Organizational Certificate Authority Object dialog box and the 
corresponding wizard that creates the object. Follow the prompts to create the object. For 
specific information on the dialog box or any of the wizard pages, click Help. 


To create the Organizational Certificate Authority object using Novell iManager: 
1 Launch Novell iManager. 


2 Log in to the eDirectory tree as an administrator with the appropriate rights. 
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To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


3 From the Roles and Tasks menu, click Novell Certificate Server > Create Certificate 
Authority. 


This opens the Create an Organizational Certificate Authority Object dialog box and the 
corresponding wizard that creates the object. Follow the prompts to create the object. For 
specific information on the dialog box or any of the wizard pages, click Help. 


NOTE: You can have only one Organizational CA for your eDirectory tree. 


Creating Server Certificate Objects 


Server Certificate objects are created in the container that holds the server's eDirectory object. 
Depending on your needs, you might create a separate Server Certificate object for each 
cryptography-enabled application on the server. Or you might create one Server Certificate object 
for all applications used on that server. 


NOTE: The terms Server Certificate Object and Key Material Object (KMO) are synonymous. The schema 
name of the eDirectory object is NDSPKI:Key Material. 


The Novell Certificate Server installation process can create a Server Certificate object for you. 
You are prompted to specify a Server Certificate object name. When you click Finish, the Server 
Certificate object is created with the default parameters and placed in the container where the 
target server resides. 


If you want more control over the creation of the Server Certificate object, you can create the 
Server Certificate object manually using ConsoleOne or Novell iManager. You can also create 
additional Server Certificate objects. 


To create additional Server Certificate objects using ConsoleOne: 
1 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see “Creating Server Certificate objects” on 
page 67. 


2 Start ConsoleOne. 


3 Right-click the container object that contains the server that will run your cryptography- 
enabled applications, then click New > Object. 


4 From the list box in the New Objects dialog box, double-click NDSPKI:Key Material. 


This opens the Create a Server Certificate dialog box and the corresponding wizard that 
creates the Server Certificate object. Follow the prompts to create the object. For specific 
information on the dialog box or any of the wizard pages, click Help. 


To create additional Server Certificate objects using Novell iManager: 
1 Launch Novell iManager. 
2 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


3 From the Roles and Tasks menu, click Novell Certificate Server > Create Server Certificate. 
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This opens the Create a Server Certificate dialog box and the corresponding wizard that 
creates the Server Certificate object. Follow the prompts to create the object. For specific 
information on the dialog box or any of the wizard pages, click Help. 


Hints for Creating Server Certificates 


During the Server Certificate object creation process, you are prompted to name the key pair and 
choose the server that the key pair will be associated with. The Server Certificate object is 
generated by Novell Certificate Server, and its name is based on the key pair name that you choose. 


If you choose the Custom creation method, you are also prompted to specify whether the Server 
Certificate object will be signed by your organization's Organizational Certificate Authority or by 
an external Certificate Authority. For information about making this decision, see “Deciding 
Which Type of Certificate Authority to Use” on page 17. 


If you decide to use your organization's Organizational CA, the server that the Server Certificate 
object is associated with must be able to communicate with the server that hosts the Organizational 
CA, or it must be the same server. These servers must be running the same protocol (IP/IPX). 


If you decide to use an external Certificate Authority to sign the certificate, the server that the 
Server Certificate object is associated with will generate a certificate signing request that you need 
to submit to the external Certificate Authority. 


After the certificate is signed and returned to you, you need to install it into the Server Certificate 
object, along with the trusted root for the external Certificate Authority. For specific information 
on any of the wizard pages, click Help. 


After you have created the Server Certificate object, you can configure your applications to use it. 
(See “Configuring Cryptography-Enabled Applications” on page 20.) Keys are referenced in the 
application’s configuration by the key pair name that you entered when you created the Server 
Certificate object. 


Configuring Cryptography-Enabled Applications 


After you have configured Novell Certificate Server, you must configure your individual 
cryptography-enabled applications so that they can use the Novell certificates that you created. 
The configuration procedures are unique to the individual applications, so we recommend that you 
consult the application’s documentation for specific instructions. 


See “Application Tasks” on page 47 for specific instructions on configuring GroupWise? 5.5 or 
later, Outlook 98, Outlook 2000, and Netscape Messenger. 


Additional Components to Set Up 


Novell Certificate Server includes some additional components that can be set up to provide 
additional functionality. 


Creating a User Certificate 


To create a user certificate using ConsoleOne: 


41 Log in to the eDirectory tree as an administrator with the appropriate rights. To view the 
appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform Tasks,” on 
page 67. 
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2 Start ConsoleOne. 

3 Double-click the User object that will host the user certificate. 
4 Click the Security tab > Certificates. 

5 Click Create. 


This opens a wizard that helps you create the user certificate. Follow the prompts to create the 
object. For specific information on the wizard pages, click Help. 


To create a user certificate using Novell iManager: 
1 Launch Novell iManager. 
2 Log in to the eDirectorv tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


3 From the Roles and Tasks menu, click Novell Certificate Server > Create User Certificate. 


This opens a wizard that helps you create the user certificate. Follow the prompts to create the 
object. For specific information on the wizard pages, click Help. 


Creating a Trusted Root Container 


You can create a Trusted Root container anywhere in the eDirectory tree. 
1 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to 
Perform Tasks,” on page 67. 


2 Start ConsoleOne. 


3 Right-click the container you want to create the Trusted Root container in, then click New > 
Object. 


4 From the list box in the New Object dialog box, double-click NDSPKI: Trusted Root. 


This opens a wizard that helps you create the Trusted Root container. Follow the prompts to 
create the object. For specific information on the wizard pages, click Help. 


NOTE: Different applications might require that the Trusted Root container be given a specific name and be 
in a specific location in the eDirectory tree. Novell Certificate Server requires that the Trusted Root container 
be named Trusted Roots and be located in the Security container. The certificates in this container are used 
to validate user certificates signed by external CAs and intermediate CA certificates stored in Trusted Root 
objects. Server certificates and the Organizational CA's certificates use the certificate chain stored in their own 
objects. 


Creating Trusted Root Objects 


A Trusted Root object can only reside in a Trusted Root Container. 


To create Trusted Root objects using ConsoleOne: 
1 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


2 Start ConsoleOne. 
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3 Open the Security container. 
4 Right-click the Trusted Root Container object, then click New > Object. 
5 From the list box in the New Object dialog box, double-click NDSPKI:Trusted Root Object. 


This opens the Create a Trusted Root Object Wizard that helps you create the trusted root 
object. Follow the prompts to create the object. For specific information on the wizard pages, 
click Help. 


To create Trusted Root objects using Novell iManager: 
1 Launch Novell iManager. 
2 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


3 From the Roles and Tasks menu, click Novell Certificate Server > Create Trusted Root. 


This opens the Create a Trusted Root Object wizard that helps you create the trusted root 
object. Follow the prompts to create the object. For specific information on the wizard pages, 
click Help. 


NOTE: Any type of certificate can be stored in a Trusted Root object (CA certificates, intermediate CA 
certificates, or user certificates). 


Creating a SAS Service Object 


To create a SAS Service object using Novell iManager: 
1 Launch Novell iManager. 
2 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


3 From the Roles and Tasks menu, click Novell Certificate Server > Create SAS Service Object. 


This opens the Create a SAS Service Object Wizard that helps you create the SAS Service 
Object. Follow the prompts to create the object. For specific information on the wizard pages, 
click Help. 
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Managing Novell Certificate Server 


As a system administrator, you will need to perform several tasks to maintain the public key 
cryptography services provided through Novell® Certificate Server™. Use Novell iManager to 
perform these tasks. This chapter provides a brief overview and specific information on 
completing each task. 


Certificate Authority tasks: 


+ 


+ 


+ 


+ 


+ 


+ 


+ 


“Creating an Organizational Certificate Authority Object” on page 18 
“Issuing a Public Key Certificate” on page 25 

“Viewing the Organizational CA's Properties” on page 25 

“Viewing an Organizational CA's Public Key Certificate Properties” on page 26 
“Viewing the CA's Self-Signed Certificate Properties” on page 26 
“Exporting the Organizational CA's Self-Signed Certificate” on page 26 
“Backing Up an Organizational CA” on page 27 

“Restoring an Organizational CA” on page 28 

“Moving the Organizational CA to a Different Server” on page 29 
“Validating the Organizational CA’s Certificates” on page 29 

“Deleting the Organizational CA” on page 30 


Server Certificate object tasks: 


+ 


+ 


+ 


+ 


“Creating Server Certificate Objects” on page 19 

“Importing a Public Key Certificate into a Server Certificate Object” on page 30 
“Exporting a Trusted Root or Public Key Certificate” on page 31 

“Deleting a Server Certificate Object” on page 32 

“Viewing a Server Certificate Object’s Properties” on page 33 

“Viewing a Server Certificate Object’s Public Key Certificate Properties” on page 33 
“Viewing a Server Certificate Object's Trusted Root Certificate Properties” on page 33 
“Backing Up a Server Certificate Object” on page 34 

“Restoring a Server Certificate Object” on page 35 

“Server Certificate Objects and Clustering” on page 36 

“Validating a Server Certificate” on page 36 

“Moving a Server Certificate Object to a Different Server” on page 37 


“Replacing a Server Certificate Object's Keving Material” on page 37 
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User Certificate tasks: 


+ 


+ 


+ 


+ 


+ 


“Creating a User Certificate” on page 20 
“Creating User Certificates in Bulk” on page 38 


“Importing a Public Key Certificate into a User Object (with or without the Private Key)” on 
page 38 


“Viewing a User Certificate’s Properties” on page 39 
“Exporting a User Certificate” on page 39 

“Exporting a User Certificate and Private Key” on page 40 
“Deleting a User Certificate and Private Key” on page 41 
“Validating a User Certificate” on page 41 


Trusted Root object tasks: 


+ 


+ 


+ 


+ 


+ 


“Creating a Trusted Root Container” on page 21 
“Creating Trusted Root Objects” on page 21 

“Viewing a Trusted Root Object's Properties” on page 42 
“Replacing a Trusted Root Certificate” on page 42 
“Validating a Trusted Root Object” on page 43 


Certificate Revocation List (CRL) Tasks: 


+ 


+ 


+ 


+ 


+ 


“Creating a CRL Object” on page 44 

“Exporting a Third-Party CRL” on page 44 
“Replacing a Third-Party CRL” on page 45 

“Viewing a Third-Party CRL’s Properties” on page 45 
“Managing Novell Certificate Server” on page 23 


Novell eDirectory® tasks: 


+ 


+ 


+ 


“Resolving Multiple Security Containers, Organizational CAs, KAP Containers, and WO 
Objects” on page 45 


“Restoring or Re-creating a Security Container” on page 46 


“Restoring or Re-creating KAP and WO” on page 46 


Application tasks: 


+ 


+ 


+ 


“Importing the User Certificate and Private Key into Your E-Mail Client” on page 47 
“Configuring Your E-Mail Client to Secure Your E-Mail” on page 48 

“Configuring Your Browser or E-Mail Client to Accept Certificates” on page 50 
“Configuring Microsoft Internet Explorer (IE) for SSL with Novell Certificates” on page 52 
“Configuring Microsoft IIS for Client Authentication with Novell Certificates” on page 52 
“Requesting a Server Certificate for Microsoft IIS” on page 52 
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Certificate Authority Tasks 


Creating an Organizational Certificate Authority Object 


This task is described in Chapter 2. See “Creating an Organizational Certificate Authority Object” 
on page 18. 


Issuing a Public Key Certificate 


This task allows you to generate certificates for cryptography-enabled applications that do not 
recognize Server Certificate objects. 


Your Organizational CA works the same way as an external CA. That is, it has the ability to issue 
certificates from Certificate Signing Requests (CSRs). You can issue certificates using your 
Organizational CA when a user sends a CSR to you for signing. The user requesting the certificate 
can then take the issued certificate and import it directly into the cryptography-enabled 
application. 


To issue a public key certificate: 
1 Launch Novell iManager. 
2 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


From the Roles and Tasks menu, click Novell Certificate Server > Issue Certificate. 
Use the Browse button to locate a CSR file, open the file, then click Next. 
Specify the key type, the key usage, and the extended key usage, then click Next. 


Specify the certificate basic constraints, then click Next. 
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Specify the subject name, the validity period, the effective and expiration dates, and any 
custom extensions, then click Next. 


8 Review the parameters sheet. If it is correct, click Finish. If not, click Back until you reach the 
point where you need to make changes. 


When you click Finish, a dialog box explains that a certificate has been created. You can save 
the certificate to the system clipboard in base64 format, to a base64-formatted file, or to a 
binary DER-formatted file. You can also click Details to view details about the issued 
certificate. 


Viewing the Organizational CA’s Properties 


Besides the eDirectory rights and properties that can be viewed with any eDirectory object, you 
can also view properties specific to the Organizational CA, including the properties of the public 
key certificate and the self-signed certificate associated with it. 


To view the Organizational CA’s properties: 
1 Launch Novell iManager. 
2 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 
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3 From the Roles and Tasks menu, click Novell Certificate Server > Create Certificate 
Authority. 


This brings up the property pages for the Organizational CA, which include a General page, 
a CRL Configuration page, and a Certificates page. 


4 Click the tabs you want to view. 


Viewing an Organizational CA’s Public Key Certificate Properties 


To view the Organizational CA's public key certificate properties: 
1 Launch Novell iManager. 
2 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


3 From the Roles and Tasks menu, click Novell Certificate Server > Create Certificate 
Authority. 


This brings up the property pages for the Organizational CA, which include a General page, 
a CRL Configuration page, a Certificates page, and other eDirectory-related pages. 


4 Click Certificates > Public Key Certificate. 
5 To view additional information about an installed public key certificate, click Details. 


6 Click Close. 


Viewing the CA's Self-Signed Certificate Properties 


To view the Organizational CA's self-signed certificate properties: 
1 Launch Novell iManager. 
2 Log in to the eDirectorv tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


3 From the Roles and Tasks menu, click Novell Certificate Server > Create Certificate 
Authority. 


This brings up the property pages for the Organizational CA, which include a General page, 
a CRL Configuration page, and a Certificates page. 


4 Click Certificates > Self Signed Certificate. 
5 To view additional information about an installed public key certificate, click Details. 


6 Click Close. 


Exporting the Organizational CA's Self-Signed Certificate 
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The self-signed certificate can be used for verifving the identitv of the Organizational CA and the 
validity of a certificate signed by the Organizational CA. 


From the Organizational CA's propertv page, vou can view the certificates and properties 
associated with this object. From the self-signed certificate property page, you can export the self- 
signed certificate to a file for use in cryptography-enabled applications. 


Novell Certificate Server 2.7.x Administration Guide 


The self-signed certificate that resides in the Organizational CA is the same as the Trusted Root 
certificate in a server certificate object that has a certificate signed by the Organizational CA. Any 
service that recognizes the Organizational CA's self-signed certificate as a trusted root will accept 
a valid user or server certificate signed by the Organizational CA. 


To export the Organizational CA's self-signed certificate: 
1 Launch Novell iManager. 
2 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


3 From the Roles and Tasks menu, click Novell Certificate Server > Create Certificate 
Authority. 


This brings up the property pages for the Organizational CA, which include a General page, 
a CRL Configuration page, a Certificates page, and other eDirectory-related pages. 


4 Click Certificates > Self Signed Certificate. 
5 Click Export. 

This starts Certificate Export wizard. Follow the prompts to export the certificate. 
6 Click Finish. 


Backing Up an Organizational CA 


Novell recommends that you back up your Organizational CA's private key and certificates in case 
the Organizational CA's host server has an unrecoverable failure. If a failure should occur, you can 
use the backup file to restore your Organizational CA to any server in the tree that has Certificate 
Server version 2.21 or higher installed. 


NOTE: The ability to back up an Organizational CA is only available for Organizational CAs created with 
Certificate Server version 2.21 or later. In previous versions of Certificate Server, the Organizational CA's 
private key was created in a way that made exporting it impossible. 


The backup file contains the CA's private key, self-signed certificate, public key certificate, and 
several other certificates necessary for it to operate. This information is stored in PKCS #12 format 
(also known as PFX). 


The Organizational CA should be backed up when it is working properly. 
To back up the Organizational CA: 
1 Launch Novell iManager. 
2 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


3 From the Roles and Tasks menu, click Novell Certificate Server > Create Certificate 
Authority. 


4 Click Certificates, then click either the Self Signed Certificate or the Public Key Certificate. 
Both certificates are written to the file during the backup operation. 


5 Click Export. 


This opens a wizard that helps you export the certificates to a file. 
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6 When asked whether to export the private key, select Yes, then click Next. 


7 Specify a password with 6 or more alphanumeric characters to use in encrypting the PFX file, 
then click Next. 


8 Click on the Save the exported certificate to a file link and provide the filename and the 
location for the backup file. 


9 Click Save. 
10 Click Close. 


The encrypted backup file is written to the location specified. It is now ready to be stored in 
a secure location for emergency use. 


IMPORTANT: The exported file should be put on a diskette or some other form of backup media and stored 
in a secure place. The password used to encrypt the file should be committed to memory or stored in a safe 
place to ensure that it is available when needed, but inaccessible to others. 


Restoring an Organizational CA 
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If the Organizational CA object has been deleted or corrupted, or if the Organizational CA's host 
server has suffered an unrecoverable failure, the Organizational CA can be restored to full 
operation using a backup file created as described in “Backing Up an Organizational CA” on 
page 27. 


The abilitv to restore an Organizational CA is onlv available in Certificate Server version 2.21 or 
later. 


NOTE: If you were unable to make a backup of the Organizational CA, the Organizational CA might still be 
recovered if NICI 2.x is installed on the server and a backup was made of the NICI configuration information. 
With NetWare 6 or later, the NICI configuration information is backed up bv default using a backup utilitv. 


To restore the Organizational CA: 
1 Launch Novell iManager. 
2 Log in to the eDirectorv tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,' on page 67. 


3 (Conditional) If the Organizational CA object still exists, you need to delete it. 
3a From the Roles and Tasks menu, click eDirectory Administration > Delete Object. 
3b Browse to and click on the Organizational CA object. 
3c Click OK. 


4 From the Roles and Tasks menu, click Novell Certificate Server > Create Certificate 
Authority. 


This opens the Create an Organizational Certificate Authority Object dialog box and the 
corresponding wizard that creates the object 


5 In the creation dialog box, specify the server that should host the Organizational CA and the 
name of the Organizational CA object. The server specified must have Certificate Server 
version 2.21 or higher installed and be up and running. 


6 Specify the Import option. 
7 Click Next. 
8 Click Read from File, then select the name of the back up file in the dialog box. 
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9 Click Open. 
10 Enter the password used to encrypt the file when the backup was made. 
11 Click Finish. 


The Organizational CA's private key and certificates have now been restored and the CA is 
fullv functional. The backup file can now be stored again for future use. 


IMPORTANT: Be sure to protect vour backup media. 


Moving the Organizational CA to a Different Server 


You can move your Organizational CA from one server to another by using the backup and restore 
procedures outlined in “Backing Up an Organizational CA” on page 27 and “Restoring an 
Organizational CA” on page 28. 


1 Make sure the Organizational CA is functional. 

2 Back up the Organizational CA. 

3 Delete the Organizational CA object. 

4 Restore the Organizational CA to the desired server. 


IMPORTANT: Be sure to protect your backup media. 


Validating the Organizational CA’s Certificates 


If you suspect a problem with a certificate or think that it might no longer be valid, you can easily 
validate the certificate using iManager. Any certificate in the NDS tree can be validated, including 
certificates issued by external CAs. 


The certificate validation process includes several checks of the data in the certificate as well as 
the data in the certificate chain. A certificate chain is composed of a root CA certificate and, 
optionally, the certificates of one or more intermediate CAs. 


A result of Valid means that all certificates in the certificate chain were found to be valid. 
Certificates are considered valid if they pass a predefined set of criteria including whether the 
current time is within the validity period of the certificate, whether it has not been revoked, and 
whether it has been signed by a CA that is trusted. Only those certificates with a CRL distribution 
point extension are checked for revocation. 


A result of Invalid means that one or more certificates in the certificate chain were found to be 
invalid or their validity could not be determined. Additional information will be provided in these 
cases about which certificate is considered invalid and why. Click Help for more information 
about the reason. 


To validate a certificate: 
1 Launch Novell iManager. 
2 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


3 From the Roles and Tasks menu, click Novell Certificate Server > Create Certificate 
Authority. 


4 Click Certificates, then click Public Key Certificate or Self Signed Certificate. 
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5 Click Validate. 


The status of the certificate is reported in the Certificate Status field. If the certificate is not 
valid, the reason is given. Click Details for information about the exact certificate that was 
considered invalid. 


6 Click OK. 


Deleting the Organizational CA 


Deleting the Organizational CA object should only be done if absolutely necessary or if you are 
restoring the Organizational CA from a backup (see “Restoring an Organizational CA” on 

page 28). The only safe way to delete the object is to do a backup first so that it can be restored 
later. 


However, there are times when the Organizational CA must be deleted and not restored. For 
example, when merging trees, only one Organizational CA can be in the resulting tree; the other 
CA must be deleted. Or, when the Organizational CA's host server has become irreparably 
damaged and no backup of the CA or the NICI configuration was made, the only option remaining 
is to delete the CA and to begin again. 


To delete the Organizational CA object: 
1 Launch Novell iManager. 
2 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


3 Back up the self signed certificate without the private key. 


4 Create a trusted root certificate using the self-signed certificate in the 
CN=trusted roots.CN=security container. 


5 From the Roles and Tasks menu, click eDirectory Administration > Delete Object. 
6 Browse to and click on the Organizational CA object. 


7 Click OK. 


Server Certificate Object Tasks 


Creating Server Certificate Objects 


This task is described in Chapter 2. See “Creating Server Certificate Objects” on page 19. 


Importing a Public Key Certificate into a Server Certificate Object 
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You import a public key certificate after you have created a certificate signing request (CSR) and 
the Certificate Authority (CA) has returned the signed public key certificate to you.This task 
applies when you have created a Server Certificate object using the Custom option with the 
External CA signing option. 


There are several ways in which the CA can return the certificate. Typically, the CA either returns 
one or more files each containing one certificate, or returns a file with multiple certificates in it. 
These files can be binary, DER-encoded files (.der, .cer, .crt., .p7b) or they can be textual, base64- 
encoded files (.cer, .b64). 
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If the file has multiple certificates in it, it must be in PKCS #7 format in order to be imported into 
a Server Certificate object. Additionally, the file must contain all of the certificates to be imported 
into the object (the root-level CA certificate, any intermediate CA certificates, and the server 
certificate). 


If the CA returns multiple files to you as a result of signing the certificate, each file will contain a 
different certificate that must be imported into the Server Certificate object. If there are more than 
two files (one for the root-level CA, one or more for the intermediate CAs, and one for the server 
certificate), these files must be combined into a PKCS #7 file in order to be imported into a Server 
Certificate object. 


There are several ways to create a PKCS #7 file. One way is to import all of the certificates into 
Internet Explorer. After they have been imported, the server certificate and all of the certificates 
in the certificate chain can be exported in PKCS #7 format using Internet Explorer. 


Some CAs do not return a root-level CA certificate along with the server certificate. In order to 
obtain the root-level CA certificate, contact the CA provider directly or call Novell Support. 


To import the certificates into a Server Certificate object: 
1 Launch Novell iManager. 
2 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


From the Roles and Tasks menu, click eDirectory Administration > Modify Object. 
Browse to and click on the Server Certificate object you want to modify. 

Click OK. 

Click the Certificates tab. 

Click Import. 


Browse for and select the certificate data file. 
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Browse for and select the trusted root data file. 
If all certificates are contained in a single file, leave this field blank. 


10 Click OK. 


Exporting a Trusted Root or Public Key Certificate 


You export a certificate to a file for the following reasons: 


+ A client (such as an Internet browser) can use it to verify the certificate chain sent by a 
cryptography-enabled application. 


+ You will have a backup copy of the file. 


You can export the certificate in two file formats: DER-encoded (.der) and Base64-encoded (.b64). 
The .crt extension can also be used for DER-encoded certificates. You can also export to the 
system clipboard in Base64 format so that it can be pasted directly into a cryptography-enabled 
application. 


To export a trusted root or public key certificate: 


1 Launch Novell iManager. 
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2 Log in to the eDirectory tree as a user with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


3 From the Roles and Tasks menu, click eDirectory Administration > Modify Object. 


4 Browse to and click on the Server Certificate object the particular application is configured to 
use. 


5 Click OK. 


6 Click the Certificates tab, and click the certificate (trusted root or public key) you want to 
expott.. 


7 Click Export. 
This opens a wizard that helps you export the certificate to a file. 
8 When asked whether or not to export the private key, click No, then click Next. 
9 Select an output format (binary DER or text encoded base64), then click Next.. 
10 Click Save the exported certificate to a file and save the file to a location of vour choice. 
11 Click Close > Close > OK. 
12 Use the file as needed. 


For example, if you want to install a trusted root certificate in an Internet Explorer browser, 
double-click the file. This initiates a wizard that will accept the CA as a trusted root. 
Accepting the CA as a trusted root means that the browser automatically accepts SSL 
connections with services that use certificates issued by this CA. 


Deleting a Server Certificate Object 


You should delete a Server Certificate object if you suspect that the private key has been 
compromised, if you no longer want to use the key pair, or if the trusted root in the Server 
Certificate object is no longer trusted. 


IMPORTANT: After the Server Certificate object is deleted, you cannot recover it unless you have previously 
made a backup. Before you delete this object, make sure that no cryptography-enabled applications still need 
to use it.You can re-create a Server Certificate Object, but you will need to reconfigure any applications that 
referenced the old object. 


To delete a Server Certificate object: 
1 Launch Novell iManager. 
2 Log in to the eDirectorv tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,' on page 67. 


3 From the Roles and Tasks menu, click eDirectorv Administration > Delete Object. 
4 Browse to and click on the Server Certificate object you want to delete. 


5 Click OK, then OK again to delete the object. 
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Viewing a Server Certificate Object’s Properties 


In addition to the eDirectory rights and properties that are viewable with any eDirectory object, 
you can also view properties specific to the Server Certificate object, including the properties of 
the public key certificate and the trusted root certificate associated with it, if they exist. 


To view a Server Certificate object's properties: 
1 Launch Novell iManager. 
2 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


3 From the Roles and Tasks menu, click eDirectory Administration > Modify Object. 
4 Browse to and click on the Server Certificate object you want to view. 
5 Click OK. 


This brings up the property pages for the Server Certificate Object, including a General page, 
a Certificates page, and property pages related to eDirectory. 


6 Click each tab you want to view. 


7 Click Cancel. 


Viewing a Server Certificate Object’s Public Key Certificate Properties 


To view a Server Certificate object’s public key certificate properties: 
1 Launch Novell iManager. 
2 Log in to the eDirectory tree as a user with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


From the Roles and Tasks menu, click eDirectory Administration > Modify Object. 
Browse to and click on the Server Certificate object you want to view. 

Click OK. 

Click Public Key Certificate. 
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+ Ifa public key certificate is installed, the property page displays the subject’s fully typed 
name, the issuer’s fully typed name, and the validity dates of the public key certificate. 


+ Ifthe public key certificate has not yet been installed, the property page indicates this. 
7 To view additional information about a public key certificate, click Details. 
The Details page has information contained in the public key certificate. 


8 Click Close > Cancel. 


Viewing a Server Certificate Object’s Trusted Root Certificate Properties 


To view a Server Certificate object’s trusted root certificate properties: 
1 Launch Novell iManager. 


2 Log in to the eDirectory tree as an administrator with the appropriate rights. 
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To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


From the Roles and Tasks menu, click eDirectory Administration > Modify Object. 
Browse to and click on the Server Certificate object you want to view. 

Click OK. 

Click Trusted Root Certificate. 
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+ Ifa trusted root certificate is installed, the property page displays the subject’s fully typed 
name, the issuer’s fully typed name, and the validity dates of the trusted root certificate. 


+ Ifthe trusted root certificate has not yet been installed, the property page indicates this. 
7 To view additional information about a trusted root certificate, click Details. 
The Details page has information contained in the trusted root certificate. 


8 Click Close > Cancel. 


Backing Up a Server Certificate Object 
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Novell Certificate Server allows you to store certificates signed by third-party Certificate 
Authorities in server certificate objects. Often these certificates cost a significant amount of 
money. Unfortunately, if an unrecoverable failure happens on the server that owns the certificates, 
the server certificate object can no longer be used. In order to protect against such failures, you 
might want to back up server certificates signed by external CAs and their associated private keys. 
Then, if a failure should occur, you can use the backup file to restore your server certificate object 
to any server in the tree that has Certificate Server version 2.21 or higher installed. 


NOTE: The ability to back up a server certificate object is only available for objects created with Certificate 
server version 2.21 or later. In previous versions of Certificate Server, the server's private key was created in 
a way that made exporting it impossible. 


The backup file contains the server's private key, public key certificate, trusted root certificate, and 
any intermediate CA certificates stored. This information is stored in PKCS #12 format (also 
known as PFX). 


A server certificate object should be backed up when it is working properly. 
To backup a Server Certificate object: 
1 Launch Novell iManager. 
2 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


From the Roles and Tasks menu, click eDirectory Administration > Modify Object. 
Browse to and click on the Server Certificate object you want to backup. 

Click OK. 

Click the Certificates tab. 
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Click either the Trusted Root Certificate or the Public Key Certificate. Both certificates are 
written to the file during the backup operation. 


8 Click Export. 


This opens a wizard that helps you export the certificates to a file. 
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9 When asked whether to export the private key, select Yes, then click Next. 
10 Specify a password with 6 or more alphanumeric characters to use in encrypting the PFX file. 
11 Click Next. 


12 Click Save the exported certificate to a file. Select the filename and the location for the backup 
file. 


13 Click Close > Close. 


The encrypted backup file is written to the location specified. It is now ready to be stored in 
a secure location for emergency use. 


IMPORTANT: The exported file should be put on a diskette or some other form of backup media and stored 
in a secure place. The password used to encrypt the file should be committed to memory or stored in a vault 
to ensure that it is available when needed, but inaccessible to others. 


Restoring a Server Certificate Object 


If the Server Certificate object has been deleted or corrupted, or if the server that owned the Server 
Certificate object has suffered an unrecoverable failure, the object can be restored to full operation 
using a backup file created as described in “Backing Up a Server Certificate Object” on page 34. 


The ability to restore a Server Certificate object is only available in Certificate Server version 2.21 
or later. 


If you were unable to make a backup of the server certificate object, the server certificate object 
may still be usable if NICI 2.x is installed on the server and a backup was made of the NICI 
configuration information. See the NICI documentation for information on how to back up and 
restore the NICI configuration files. 


To restore the server certificate object: 
1 Launch Novell iManager. 
2 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


3 Delete the old server certificate object. 
4 From the Roles and Tasks menu, click Novell Certificate Server > Create Server Certificate. 
This opens the Create a Server Certificate Wizard that creates the object. 


5 Inthe wizard, specify the server that should own the server certificate object and the certificate 
nickname of the server certificate. The server specified must have Certificate Server version 
2.21 or higher installed and be up and running. 


6 Specify the Import option, then click Next. 


7 Browse for and select the backup file and enter the backup file password, then click Finish. 


The server's private key and certificates have now been restored and the server certificate object is 
fully functional. The backup file can now be stored again for future use if desired. 


IMPORTANT: Be sure to protect your backup media. 
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Server Certificate Objects and Clustering 


You can set up server certificate objects in a clustered environment to ensure that your 
cryptography-enabled applications that use server certificate objects will always have access to 
them. Using the backup and restore feature for server certificate objects, you can duplicate the 
object’s keying material from one node in the cluster to all nodes. Keying material signed by an 
external CA saves you money by allowing you to duplicate the keying material for one server 
certificate rather than requiring new keying material for every node in the cluster. 


To set up server certificates to work in a clustered environment: 


1 Create a server certificate on a server in the cluster using either the Organizational CA or an 
external CA of your choice. See “Creating Server Certificate Objects” on page 19. 


When you create the server certificate objects, the Common Name (CN) portion of the 
certificate’s subject name should be an IP or DNS name that is specific to the service. 
Otherwise, you will receive a browser warning message indicating that the IP or DNS name 
on the URL does not match that in the certificate. 


NOTE: If different services have different IP or DNS addresses, you need to create a server certificate 
for each service. 


2 Back up the keying material for this server certificate object and restore it by creating a server 
certificate object with the identical key pair name as the first on all remaining servers in the 
cluster. See “Backing Up a Server Certificate Object” on page 34. 


Validating a Server Certificate 
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If you suspect a problem with a certificate or think that it might no longer be valid, you can easily 
validate the certificate using iManager. Any certificate in the eDirectory tree can be validated, 
including certificates issued by external CAs. 


The certificate validation process includes several checks of the data in the certificate as well as 
the data in the certificate chain. A certificate chain is composed of a root CA certificate and, 
optionally, the certificates of one or more intermediate CAs. 


A result of Valid means that all certificates in the certificate chain were found to be valid. 
Certificates are considered valid if they pass a predefined set of criteria including whether the 
current time is within the validity period of the certificate, whether it has not been revoked, and 
whether it has been signed by a CA that is trusted. Only those certificates with a CRL distribution 
point extension are checked for revocation. 


A result of Invalid means that one or more certificates in the certificate chain were found to be 
invalid or their validity could not be determined. Additional information is provided in these cases 
about which certificate is considered invalid and why. Click Help for more information about the 
reason. 


To validate a certificate: 
1 Launch Novell iManager. 
2 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


3 From the Roles and Tasks menu, click eDirectory Administration > Modify Object. 


4 Browse to and click on the Server Certificate object you want to validate. 
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Click OK. 

Click the Certificates tab. 

Click either Trusted Root Certificate or Public Key Certificate. 
Click Validate. 


The status of the certificate is provided in the Certificate Status field. If the certificate is not 
valid, the reason is given. Click Details for information about the exact certificate that was 
considered invalid. 
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Moving a Server Certificate Object to a Different Server 


You can move a Server Certificate Object from one server to another by using the backup and 
restore procedures outlined in “Backing Up a Server Certificate Object” on page 34 and 
“Restoring a Server Certificate Object” on page 35. 


1 Make sure the Server Certificate Object is functional. 
2 Back up the Server Certificate Object. 


3 Restore the Server Certificate Object to the desired server. 
IMPORTANT: Be sure to protect your backup media. 


Replacing a Server Certificate Object’s Keying Material 


The private key and certificates in the server certificate object can be replaced. They should only 
be replaced using an internally generated PFX file created during a backup of a server certificate 
object. Externally generated PFX files can also be used if they contain the private key, the server 
certificate, and the entire certificate chain. The key and certificates in the file need not match the 
ones in the object; the data in the file will overwrite the key and certificates in the object. 


Replacing the private key and certificates in the server certificate object is a serious matter. If the 
key and certificates do not exactly match the ones in the object, it is the same as deleting the current 
server certificate object and creating a new one. See the section “Deleting a Server Certificate 
Object” on page 32 for more information on the consequences of deleting the object. 


If the key and certificates do match the ones in the object, replacing the keying material will have 
no effect except to regenerate a few attributes used by the Secure Authentication Services (SAS) 
and NILE services. 


To replace the keying material on the Server Certificate object: 


1 As a precaution, back up the server certificate object with the private key. See “Backing Up a 
Server Certificate Object” on page 34. 


2 Launch Novell iManager. 
3 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


From the Roles and Tasks menu, click eDirectory Administration > Modify Object. 
Browse to and click on the Server Certificate object you want to modify. 


Click OK. 
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Click the Certificates tab. 
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8 Click either the Trusted Root Certificate or the Public Key Certificate. 


The operation can be started from either page. It replaces both certificates as well as the 
private key and any other certificates in the certificate chain. 


9 Click Replace. 
This opens a wizard that helps you specify the PFX (backup) file. 
10 Browse for and select the backup file, enter the backup file password, then click OK. 


The server's private key and certificates have now been replaced and the server certificate is fully 
functional. The backup file should be stored again for future use if desired. 


IMPORTANT: Be sure to protect your backup media. 


User Certificate Tasks 


Creating User Certificates 


This task is described in Chapter 2. See “Creating a User Certificate” on page 20. 


Creating User Certificates in Bulk 


This feature allows you to create user certificates for multiple users at the same time using one 
sequence of operations. 


To create user certificates in bulk: 
1 Launch Novell iManager. 
2 Log in to the eDirectorv tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,' on page 67. 


3 From the Roles and Tasks menu, click Novell Certificate Server > Create User Certificate. 
This opens a wizard that helps vou create the user certificate. 
4 Browse for and select all users you want to create a user certificate for. 


5 Follow the wizard prompts to create the certificate for each user. For specific information on 
the wizard pages, click Help. 


Importing a Public Key Certificate into a User Object (with or without the Private 
Key) 


You can import any public key certificate into a user object (for example, a certificate signed by a 
third-party Certificate Authority). This certificate can appear as one of two types of files: 


+ DER — contains a public key certificate only. 
+ PFX or PKCS#12 — contains a public key certificate as well as a private key. 


Once imported, the certificate is stored in the User object and appears on the list of certificates 
available. 


NOTE: When importing a PKCS#12 certificate, only the public key certificate and private key are stored on 
the user object. No other certificates are stored. Other certificates in the user's certificate chain should 
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probably be stored in the CN=Trusted Roots.CN=Security container (create a new Trusted Root object for 
each certificate in the chain). 


To import a Public Key Certificate into a User object: 


1 
2 
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Launch Novell iManager. 
Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


From the Roles and Tasks menu, click Novell Certificate Access > View User Certificates. 
Browse for and select a User object to import the public key certificate into. 

Click Import. 

Enter a nickname for the user certificate. 


The nickname should be unique and should help you identify the certificate. You can enter up 
to 64 characters in the Certificate Nickname field. 


Browse for and select the certificate to import, then click OK. 


(Conditional) If importing a certificate with a private key, enter the password for the private 
key, then click OK. 


Click OK. 


This stores the certificate in the User object, and the certificate appears on the list of 
certificates available to this user. 


Viewing a User Certificate’s Properties 


In addition to the eDirectory rights and properties that are viewable with any eDirectory object, 
you can also view properties specific to the user certificate, including the issuer, the certificate 
status, the private key status, and the validation period. 


To view a user certificate's properties: 


1 
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Launch Novell iManager. 
Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


From the Roles and Tasks menu, click Novell Certificate Access > View User Certificates. 
Browse for and select a User object whose certificate properties you want to view. 
Click a certificate to view its properties. 


Click OK when you are done viewing. 


Exporting a User Certificate 


In order to exchange secure e-mail with another person, you must first have the other person's 
public key certificate. One way of obtaining that certificate is to export it using iManager. The 
other person's certificate can also be obtained using LDAP or e-mail. 


To export your own or any other user's public key certificate: 
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4 Launch Novell iManager. 
2 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,' on page 67. 


3 From the Roles and Tasks menu, click Novell Certificate Access > View User Certificates. 
4 Browse for and select a User object whose certificate vou want to export. 
5 Click Export. 


This opens a wizard that helps you export the user certificate to a file. If you are logged in as 
the user that owns the certificate, select No when asked if vou want to export the private kev. 
See “Exporting a User Certificate and Private Key” on page 40. 


6 Select an output format, then click Next. 
7 Click Save the exported certificate to a file and save the file to a location of your choice. 


8 Click Close > Close. 


Exporting a User Certificate and Private Key 
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In order to use a certificate for secure e-mail, authentication, or encryption, both the private key 
and the certificate must be available to the cryptography-enabled application. You must export the 
user certificate and private key and place it in a location that the application has access to in order 
for the application to use them. 


The private keys in a user's object belong to that user. Only someone logged in as that user can 
export the private key. No other user, not even the network administrator, has rights to export 
another user's private key. 


To export your own private key and certificate: 
1 Launch Novell iManager. 
2 Log in to the eDirectorv tree as the user who owns the certificate. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,' on page 67. 


3 From the Roles and Tasks menu, click Novell Certificate Access > View My Certificates. 
4 Click Export. 


This opens a wizard that helps you export the user certificate to a file. If you are not logged 
in as the user who owns the certificate, you will not be able to export the private key. If you 
are logged in as that user, you are asked whether to export the private key as well. Select Yes. 


5 Select an output format, then click Next. 
6 Select the filename and the location for the exported file. 


7 Specify a password with 6 or more alphanumeric characters to use in encrypting the PFX file, 
then click Next. 


8 Click Close > Close. 


The encrypted file is written to the location specified. It is now ready to be imported into a 
cryptography-enabled application. 
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IMPORTANT: The exported file can be kept to provide a backup. If so, it should be stored in a secure place. 
The password used to encrypt the file should be committed to memory or stored in a safe place to ensure that 
it is available when needed, but inaccessible to others. 


Validating a User Certificate 


If vou suspect a problem with a certificate or think that it might no longer be valid, vou can easilv 
validate the certificate using iManager. Anv certificate in the eDirectorv tree can be validated, 
including certificates issued bv external CAs. 


The certificate validation process includes several checks of the data in the certificate as well as 
the data in the certificate chain. A certificate chain is composed of a root CA certificate and, 
optionally, the certificates of one or more intermediate CAs. 


A result of Valid means that all certificates in the certificate chain were found to be valid. 
Certificates are considered valid if they pass a predefined set of criteria including whether the 
current time is within the validity period of the certificate, whether it has not been revoked, and 
whether it has been signed by a CA that is trusted. Only those certificates with a CRL distribution 
point extension are checked for revocation. 


A result of Invalid means that one or more certificates in the certificate chain were found to be 
invalid or their validity could not be determined. Additional information is provided in these cases 
about which certificate is considered invalid and why. Click Help for more information about the 
reason. 


To validate a certificate: 
1 Launch Novell iManager. 
2 Log in to the eDirectorv tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,' on page 67. 


3 From the Roles and Tasks menu, click Novell Certificate Access > View User Certificates. 
4 Browse for and select a User object whose certificate you want to validate. 
5 Click Validate. 


The status of the certificate is provided in the Certificate Status field. If the certificate is not 
valid, the reason is given. Click Details for information about the exact certificate that was 
considered invalid. 


NOTE: If the user certificate was signed by a third-party CA, the certificate chain must be in the Trusted Roots 
container in the Security container (CN=Trusted Roots.CN=Security) for the validation to succeed. Typically, 
the certificate chain consists of a single, root-level CA or it consists of an Intermediate CA and a root-level CA. 
The name of the Trusted Roots container must be Trusted Roots and each certificate in the chain must be 
stored in its own Trusted Root object. For instructions on how to create a Trusted Roots container and Trusted 
Root objects, see “Creating a Trusted Root Container” on page 42 and “Creating a Trusted Root Object” on 
page 42. 


When validating user certificates or intermediate CA certificates signed by external CAs, the external CA's 
certificate must be stored in a Trusted Root object in order for the certificate validation to be successful. The 
Trusted Root object must be in a Trusted Root Container named Trusted Roots and it must be located in the 
Securitv container. 


Deleting a User Certificate and Private Kev 


If a user certificate has become invalid or vou suspect the private kev has been compromised in 
some way, you might need to delete the user certificate and private key. 
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To delete a user certificate and private key: 


1 
2 


Launch Novell iManager. 


Log in to the eDirectory tree as the user who owns the certificate or as an administrator with 
the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


From the Roles and Tasks menu, click Novell Certificate Access > View My Certificates if 
you are logged in as the user or click Novell Certificate Access > View User Certificates if 
you are logged in as an administrator. 


Browse for and select a User object whose certificate you want to delete. 


Click Delete. 


Trusted Root Object Tasks 


Creating a Trusted Root Container 


This task is described in Chapter 2. See “Creating a Trusted Root Container” on page 21. 


Creating a Trusted Root Object 


This task is described in Chapter 2. See “Creating Trusted Root Objects” on page 21. 


Viewing a Trusted 


Root Object’s Properties 


In addition to the eDirectory rights and properties that are viewable with any eDirectory object, 
you can also view properties specific to the Trusted Root object, including the issuer, the certificate 
status, and the validation period. 


To view a Trusted Root object’s properties: 


1 
2 
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Launch Novell iManager. 
Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


From the Roles and Tasks menu, click eDirectory Administration > Modify Object. 
Browse to and click on the Trusted Root object you want to view. 

Click OK. 

Click each tab you want to view. 


Click Cancel. 


Replacing a Trusted Root Certificate 


This task allows you to replace a Trusted Root Certificate that is stored in the Trusted Root object. 
This task should be performed if the Trusted Root Certificate has expired. 


You can replace a Trusted Root Certificate from the Trusted Root object’s property page. 
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To replace a Trusted Root certificate: 
1 Launch Novell iManager. 
2 Log in to the eDirectorv tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


From the Roles and Tasks menu, click eDirectory Administration > Modify Object. 
Browse to and click on the Trusted Root object you want to replace. 

Click Replace. 

Browse for and select the new Trusted Root certificate. 


Click OK. 
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Validating a Trusted Root Object 


If you suspect a problem with a certificate or think that it might no longer be valid, you can easily 
validate the certificate using iManager. Any certificate in the eDirectory tree can be validated, 
including certificates issued by external CAs. 


The certificate validation process includes several checks of the data in the certificate as well as 
the data in the certificate chain. A certificate chain is composed of a root CA certificate and, 
optionally, the certificates of one or more intermediate CAs. 


A result of Valid means that all certificates in the certificate chain were found to be valid. 
Certificates are considered valid if they pass a predefined set of criteria including whether the 
current time is within the validity period of the certificate, whether it has not been revoked, and 
whether it has been signed by a CA that is trusted. Only those certificates with a CRL distribution 
point extension are checked for revocation. 


A result of Invalid means that one or more certificates in the certificate chain were found to be 
invalid or their validity could not be determined. Additional information is provided in these cases 
about which certificate is considered invalid and why. Click Help for more information about the 
reason. 


To validate a Trusted Root certificate: 
1 Launch Novell iManager. 
2 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


3 From the Roles and Tasks menu, click eDirectory Administration > Modify Object. 
4 Browse to and click on the Trusted Root object you want to validate. 
5 Click Validate. 


The status of the certificate is provided in the Certificate Status field. If the certificate is not 
valid, the reason is given. Click Details for information about the exact certificate that was 
considered invalid. 
NOTE: If the certificate in the object is not self-signed, its certificate chain must be in the Trusted Roots 
container in the Security container (CN=Trusted Roots.CN=Security) for the validation to succeed. Typically, 


the certificate chain consists of a single, root-level CA or it consists of an Intermediate CA and a root-level CA. 
The name of the Trusted Roots container must be Trusted Roots and each certificate in the chain must be 
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stored in its own Trusted Root object. For instructions on how to create a Trusted Roots container and Trusted 
Root objects, see “Creating a Trusted Root Container” on page 42 and “Creating a Trusted Root Object” on 
page 42. 


Certificate Revocation List (CRL) Tasks 


Creating a CRL Object 


This task allows you to create a CRL Distribution Point object in eDirectorv. This object can be 
created in any container in the eDirectory tree. As part of the creation process, you are asked to 
provide a CRL. You need to obtain a CRL from a third-party CA. If you don't have a CRL file at 
the time you create the CRL Distribution Point object, you can still create the object and import 
the CRL later. 


NOTE: The term CRL Distribution Point is used in a couple of wavs. It is the eDirectorv schema object name 
for the CRL object and it can be used in general terms as the point where the CRL information is published. 


To create a CRL object: 
1 Launch Novell iManager. 
2 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,' on page 67. 


From the Roles and Tasks menu, select Novell Certificate Server P Create CRL Object. 
Tvpe a name for the object and provide the context where vou want the object to reside. 


Paste a copy of the CRL into the field or read it from a CRL file. 
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Click OK to create the object. 


Importing a Third-Party CRL 
This task allows you to import a CRL signed by a third-party certificate authority into a CRL 
Distribution Point object. This option is only active if no CRL is present in the object. 
1 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


2 Start ConsoleOne. 
3 Double-click the CRL Distribution Point object that you want to import the CRL into. 
4 Click Import. 


If the Import button is not active, it means that this CRL Distribution Point object already 
contains a CRL. You can replace the existing CRL by clicking Replace. 


5 Paste a copy of the CRL into the field or read it from a CRL file. 
6 Click Finish. 


Exporting a Third-Party CRL 


You can export the CRL that is contained in the CRL Distribution Point object to a file. 
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1 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


2 Start ConsoleOne. 
3 Double-click the CRL Distribution Point object that you want to export the CRL from. 
4 Click Export. 


If the Export button is not active, it means that this CRL Distribution Point object does not 
contain a CRL. You can import a CRL by clicking Import. 


5 Select the format you want to save the CRL to (binary encoded DER or text encoded Base64), 
then specify a filename. 


The extension for the file is .crl by default. You can also browse to select the location that the 
file will be saved to. 


6 Click Export. 


Replacing a Third-Party CRL 


1 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights of this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


2 Start ConsoleOne. 
3 Double-click the CRL Distribution Point object that contains the CRL you want to replace. 
4 Click Replace. 


If the Replace button is not active, it means that this CRL Distribution Point object does not 
contain a CRL. You can import a CRL by clicking Import. 


5 Paste a copy of the new CRL into the field or read it from a CRL file. 
6 Click Finish. 


Viewing a Third-Party CRL’s Properties 
1 Log in to the eDirectory tree as an administrator with the appropriate rights. 


To view the appropriate rights for this task, see Appendix B, “Entry Rights Needed to Perform 
Tasks,” on page 67. 


2 Start ConsoleOne. 
3 Double-click CRL Distribution Point object. 


eDirectory Tasks 


Resolving Multiple Security Containers, Organizational CAs, KAP Containers, and 
WO Objects 


Novell Certificate Server can be installed on multiple servers in an eDirectory tree. However, for 
Novell Certificate Server to function properly, only one Security container, Organizational CA, 
KAP container, and WO object should exist in the tree. 
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If you are installing Novell Certificate Server on multiple servers in an eDirectory tree, you must 
allow eDirectory to replicate between each installation of Novell Certificate Server. If you do not 
allow eDirectory to replicate, your installation to another server might not recognize that the tree 
already has a Security container, an Organizational CA, a KAP container, and a WO object and 
might re-create these objects on another server in the same eDirectory tree. 


The items below describe possible scenarios and how to resolve them. 


+ Ifyou have two or more Security containers in the same eDirectory tree and each contains an 
Organizational CA, and a KAP container with a WO object, do not issue any certificates. 
Contact Novell Support for help in resolving this. 


+ If you have one Security container that contains two KAP containers in the same eDirectory 
tree, do not issue any certificates. Contact Novell Support for help in resolving this. 


+ If you have one Security container that contains two Organizational CAs and one KAP 
container with a WO object in the same eDirectory tree, delete every server and user certificate 
issued by both Organizational CAs. Then, delete both CAs and create a new Organizational 
CA. Issue new server and user certificates as needed. 


+ Ifyou have two or more Security containers in the same eDirectory tree and each contains an 
Organizational CA, but only one contains a KAP container with a WO object, delete every 
server and user certificate issued by all Organizational CAs. Delete all the Security containers 
without the KAP container and WO object. If the remaining Security container is not named 
Security, rename it to Security. Issue new server and user certificates as needed. 


+ Ifyou have two or more Security containers in the same eDirectory tree and only one contains 
an Organizational CA and a KAP container with a WO object, delete all the Security 
containers without the KAP container and WO object. If the remaining Security container is 
not named Security, rename it to Security. 


Restoring or Re-creating a Security Container 


If you delete the Security container, you cannot create an Organizational Certificate Authority 
until you have restored or re-created the security container. 


To restore the security container, you must restore the eDirectory partition containing the Security 
container. 


To re-create the Security container, use one of two methods: 


+ Using iManager, click eDirectory Administration > Create Object. Click Tree’s Security 
Container, then click OK. The container name must be Security. 


+ Reinstall Novell Certificate Server on any server in the eDirectory tree. 


Restoring or Re-creating KAP and WO 
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Do not delete the KAP or WO objects. Doing so invalidates all previously created User certificates. 
If you delete one of these objects, go to the Novell Support Web site (http:// 
www.support.novell.com/search/kb_index.htm) and search for TID #10053572, How to Restore 
or Recreate KAP and WO Objects, for information on how to resolve this problem. You should not 
attempt further installations of Novell Certificate Server, Single Sign-on, NMAS, NetWare or 
eDirectory until the problems have been corrected. 
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Application Tasks 


This section describes how to configure the GroupWise® 6.x and 5.5 enhancement pack client, 
Groupwise 6.x, Outlook 98, Outlook 2000, and Netscape Messenger to use Novell certificates for 
secure e-mail. This section also describes how to configure other cryptography-enabled 
applications to use Novell certificates. 


Some of the information in this section is dated but useful. For the latest information on using 
certificates with your cryptography-enabled applications, refer to the application's documentation. 


The general process for enabling applications for secure e-mail is: 


1. Export your Organizational CA's self-signed certificate, your user certificate, and the 
matching private kev to a .pfx file. 


2. Import the .pfx file into vour e-mail client. 


3. Configure your e-mail client to secure your e-mail. 


Importing the User Certificate and Private Key into Your E-Mail Client 


Installing a user certificate and private key (a .pfx file) into Internet Explorer automatically makes 
it available for use by GroupWise and Microsoft Outlook. The reverse is also true. Installing the 
certficate and private key into either e-mail application automatically makes it available for use by 
the other e-mail application and by Internet Explorer. 


Installing a user certificate and private key into Netscape automatically makes it available for use 
by Netscape Messenger. The reverse is also true. 


Groupwise 6.x and GroupWise 5.5 Enhancement Pack Client 
1 Launch GroupWise. 
Click Tools > Options. 
Double-click the Certificates icon. 
Click Import. 
Browse for or enter the filename of your exported .pfx file. 


Enter your password, then click OK. 
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Click Set Security Level if you want to change the default security level for your private key, 
then click OK. 


8 To select a default certificate to use for sending signed e-mail, you can now either select the 
check box next to the certificate or select the certificate and click Set as Default. 


9 Click OK. 


Microsoft Outlook 98 

Launch Outlook. 

Click Tools > Options. 

Click the Security tab. 

Click Import/Export Digital ID. 
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Select the Import existing Exchange or S/MIME Security Information radio button. 
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6 For Import File and Password, type the filename and password of your exported .pfx file. 
7 For Keyset, type a nickname. This can be any text. 
8 Click OK to import the private key and certificate into Outlook98. 


Microsoft Outlook 2000 


This procedure applies to Outlook 2000 with Microsoft Internet Explorer version 5. 
1 Launch Outlook. 
2 Click Tools > Options. 
3 Click the Security tab. 
4 Click Import/Export Digital ID. 
5 Select the Import existing Exchange or S/MIME Security Information radio button. 
6 For Import File and Password, type the filename and password of your exported .pfx file. 
7 For Digital ID Name, type a nickname. This can be any text. 


8 If you are prompted to add the Organizational CA certificate to the Root Store, click Yes. 


Netscape Messenger 4.x 


1 Launch Netscape Messenger. 


2 Click the New Msg icon. 
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Double-click the Security icon on the Navigation toolbar. 


4 Click Certificates > Yours. 
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Click Import a Certificate. If you password-protected the Communicator Certificate database, 
enter the password. 


6 Type or browse for the filename of the exported .pfx file. 
7 Type the password you used to protect the .pfx file. 
8 Click OK. 


Configuring Your E-Mail Client to Secure Your E-Mail 


GroupWise 6.x Client 
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Vou must have imported at least one certificate and private key (.pfx file) into GroupWise or 
Internet Explorer in order to make use of signed e-mail. You must also have a certificate available 
for each recipient that you want to send encrypted email to. 


1 Launch GroupWise. 

2 Click Tools > Options. 

3 Click the Security tab. 

4 Click the Send Options tab. 


5 To enable signing as the default for all outgoing email, click the check box next to Sign 
Digitally. To enable encryption as the default for all outgoing e-mail, click the check box next 
to Encrypt for Recipients. 


Novell Certificate Server 2.7.x Administration Guide 


6 Click OK. 
7 Double-click the Certificates icon. 


8 Select the certificate that you want to use for signing, encryption, or both, then click the Set 
As Default button. 


If the certificate can be used for both signing and encryption, it will be the default certificate 
used for both signing and encryption. If you have two certificates, one that can only be used 
for signing and one that can only be used for encryption, the former should be set as the default 
for signing and the latter as the default for encryption. 


From an item view (send mail, post message, task, reminder note, etc.), you can change the default 
securitv options for this particular item bv selecting File P Properties and clicking the Securitv tab. 
From here you can change the signing and encryption options. 


From an item view (send mail, post message, task, reminder note, etc.), vou can also toggle the 
selection of either signing or encryption for this particular item by clicking the Encrypt or Digitally 
Sign icons at the top of the view. 


GroupWise 5.5 Enhancement Pack Client 


Microsoft Outlook 


You must have imported at least one certificate and key into GroupWise in order to make use of 
signed e-mail. You must also have a certificate available for each recipient that you want to send 
encrypted e-mail to. 


4 Launch GroupWise. 
Click Tools > Options. 
Double-click the Security icon. 


Click the Send Options tab. 
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To enable signing as the default for all outgoing e-mail, click the check box next to Sign 
Digitally Using. You can then select a different certificate to use from the Certificate drop- 
down list below this option. 


6 To enable encryption as the default for all outgoing e-mail, check the check box next to 
Encrypt for Recipient Using. You can then select the encryption method from the Method 
drop-down list below this option. The available encryption methods depend on the security 
service provider you have selected. 


7 To select a different Security Service Provider, select a provider from the Name drop-down 
list, then click OK. 


From an item view (send mail, post message, task, reminder note, etc.), you can change the default 
security options for this particular item by selecting File > Properties and clicking the Security tab. 
From here you can change the signing and encryption options. 


From an item view (send mail, post message, task, reminder note, etc.), you can also toggle the 
selection of either signing or encryption for this particular item by clicking the Encrypt or Digitally 
Sign icons at the top of the view. 


4 Launch Outlook. 
2 Click Tools > Options. 
3 Click the Security tab. 
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4 Click either Setup Secure E-Mail or Change Settings, depending on whether you have 
previously entered security settings. 


5 Select S/MIME for the Secure Message Format. 
6 Click the Choose button on the Signing Certificate line. 


7 Select the certificate that you will use for digitally signing e-mail that you send to others, then 
click OK. 


8 Click the Choose button on the Encryption Certificate line. 


9 Select the certificate that others will use for encrypting e-mail that they send to you, then click 
OK. 


10 Check the Send These Certificates with Signed Message check box, then click OK. 


11 Select the combination of options you prefer in the Secure E-Mail section, then click OK. 


Netscape Messenger 


Launch Netscape Messenger. 
Click the New Msg icon. 
Click the Security icon. 
Click Messenger. 
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Select the certificate you will use for digitally signing your e-mail that you send to others 
under the Certificate Signed and Encrypted Messages heading. 


You can select other options as desired on this page. Refer to the Netscape help topics for 
further information on these options and their purposes. 


Configuring Your Browser or E-Mail Client to Accept Certificates 
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In order to accept signed e-mail from another person or to create an SSL connection to a server on 
the Internet with your browser, you must trust the CA that signed the user or server's certificates. 
If you do not, your application might present you with an error. Some applications provide a 
warning with the ability to accept or reject the user or server certificate whose CA isn’t yet known 
to the application. 


Server and user certificates signed by a company’s Organizational CA always generates such 
warnings and errors. This is because the Organizational CA is not listed as a trusted CA in your 
application. The warnings and errors can be prevented by installing the self-signed certificate of 
the Organizational CA into your application. 


NOTE: Installing the Organizational CA into Internet Explorer automatically adds it as a trusted CA to Microsoft 
Outlook and GroupWise. Installing the Organizational CA certificate into Netscape automatically adds it as a 
trusted CA to Netscape Messenger. 


To accept the Organizational CA as a trusted CA in your application, first export the 
Organizational CA’s self-signed certificate as described in “Exporting the Organizational CA’s 
Self-Signed Certificate” on page 26. Then import it into your browser according to the directions 
below. 


NOTE: The following Internet browsers only recognize certificates that have been exported in .DER or a .CRT 
format. Although .B64 is an optional export format, it is not recognized by these Internet browsers. 
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Microsoft Internet Explorer Version 5 and 6 


Netscape Navigator 


If you are using Microsoft Internet Explorer version 5, complete the following to import the 
Organizational CA's certificate: 


1 Launch Microsoft Internet Explorer. 
2 Click File > Open. 


3 Enter or browse for the filename of the exported Organizational CA's self-signed certificate, 
then click OK. 


This opens the Certificate dialog box. 
4 Select Install Certificate. 

This opens the Certificate Manager Import Wizard. 
5 Click Next. 


6 Select the area where you want to store the certificate, then click Next, click Finish, then click 
Yes. 


If you have installed either Microsoft Internet Explorer 5.x or NT 4 Service Pack 4 or later on your 
workstation, you must complete the following steps to import the Organizational CA's self-signed 
certificate into Netscape Navigator. This is necessary because the Microsoft products intercept 
opening trusted root files with a .crt or .der extension. 


1 Run the x509.reg file to install the X.509 extension. On a NetWare server, this file is located 
at sys:\public\mgmt. On an NT\2000 server, this file is located in the 
<drive_letter>:novell\nds directory. 


Rename the Organizational CA's self-signed certificate file with an X.509 extension. 
Launch Netscape Navigator. 

Click File P Open Page. 

Enter or browse for the filename of the self-signed certificate with the X.509 extension. 


Click Open. 
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The New Certificate Authority dialog box should appear. If it doesn’t, you have not correctly 
installed the .x509 extension, or you have not correctly renamed the self-signed certificate. 


7 Follow the wizard. Make sure that the Accept this Certificate Authority for Certifying E-Mail 
Users check box is checked. 


8 Click Next until the dialog box to enter a short name for this Certificate Authority appears. 
9 Click Finish. 


If you have not installed either Microsoft Internet Explorer 5.x or NT 4 Service Pack 4 or later, you 
must complete the following steps to import the Organizational CA’s certificate into Netscape 
Navigator: 


1 Launch Netscape Navigator. 
2 Select File > Open Page. 
3 Enter or browse for the filename of the self-signed certificate you previously exported. 


4 Click Open. 
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5 Follow the wizard. Make sure the Accept this Certificate Authority for Certifying E-Mail 
Users check box is checked. 


6 Click Next until the dialog box to enter a short name for this Certificate Authority appears. 
7 Click Finish. 


Configuring Microsoft Internet Explorer (IE) for SSL with Novell Certificates 


To configure IE to use Novell certificates for SSL, you must first install Your self-signed 
Organizational CA certificate in your IE browser, as described in “Configuring Your Browser or 
E-Mail Client to Accept Certificates' on page 50. Otherwise, any attempt to use IE to connect to 
a server that is using Novell certificates for SSL will only display an error. 


This configuration is not strictly necessary for the Netscape browser, which will present a dialog 
box for you to accept or reject a server certificate whose CA isn't yet known to the browser. 


Configuring Microsoft IIS for Client Authentication with Novell Certificates 


To perform client authentication to IIS with Novell user certificates, your self-signed 
Organizational CA certificate must first be installed in IIS as a trusted root. Use Microsoft Internet 
Explorer (IE) version 4 or later to install your Organizational CA certificate on the IIS computer 
as described in the IIS online documentation. 


However, the IISCA program described in the IIS documentation does not work on Windows NT 
with Service Pack 4 or later. In this case, when you use IE to install the certificate and the 
Certificate Manager Import wizard has started, perform the following to complete the process 
correctly: 


1 Select Place All Certificates into the Following Store. 

2 Click Browse to open the Select Certificate Store dialog box. 

3 Check the Show Physical Stores check box. 

4 Expand Trusted Root Certification Authorities and select Local Computer. 
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Click OK > Next to open the Completing the Certificate Manager Import Wizard summary 
page. Before clicking Finish, verify that the summary displays Certificate Store Selected by 
User and Trusted Root Certification Authorities/Local Computer. 


6 Stop and restart the IIS services after installing your Organizational CA certificate. 


For further information, refer to Microsoft Knowledgebase articles Q218445 and Q216339. 


Requesting a Server Certificate for Microsoft IIS 
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When using the IIS management tools to create an SSL key pair and certificate signing request 
(CSR), select Put the Request in a File that You Will Send to an Authority in the Create New Key 
wizard. You can then use your Organizational CA to issue a server certificate from the IIS CSR as 
described in “Issuing a Public Key Certificate” on page 25. 


However, you must first edit the IIS CSR to delete all text that precedes the line: 


= BEGIN NEW CERTIFICATE REQUEST ----- 


This line must be the first line in the CSR input to the Novell Certificate Server. Refer to the HS 
online documentation for further instructions on installing the resulting server certificate and 
configuring IIS for SSL. 
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Troubleshooting 


This section provides troubleshooting information for known issues. 


If you do not find a solution to your issue here, check the Readme file that accompanied the 
software as well as the Novell® Support information database (http://www.support.novell.com). 


Using PKIDiag 
PKIDiag is a NetWare® utility designed to diagnose and fix Certificate Server objects. PKIDiag 
can be used to do the following: 


+ Rename or move server-related objects so that they conform to the correct naming and 
containment scheme if a server has been moved. 


+ Create required objects if they do not exist. 

+ Grant the necessary rights between objects. 

¢ Link objects if they are not linked. 

+ Create the SSL CertificateIP and the SSL CertificateDNS certificates if they do not exist. 


+ Fix the SSL CertificateIP and the SSL CertificateDNS certificates if either has an incorrect 
name, is out of date, or is close to expiring. 


To load PKIDiag, at a server prompt type 

Load PKIDiag 

To see a list of command line options, at a server prompt type 
Load PKIDiag /? 


See TID #10089099 (http://support.novell.com/cgi-bin/search/searchtid.cgi?/10089099.htm) for 
more information about PKIDiag and how it can be used. 


Installation Issues 
File Data Conflict During Installation 


If you receive a message indicating that a newer file exists from the previous installation, you 
should select to always overwrite the newer file. 
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Incomplete List of Servers 


The list of servers shown during the installation might not list servers that are configured to use 
only IP. You can install Novell Certificate Server™ on a server whose name is not listed by typing 
the name of the server in the text box. 


Error Creating SAS Service Object During Install 


When installing Novell Certificate Server, you might encounter an error stating that the Security 
Domain key server could not be contacted. The first server in your network that you install Novell 
Single Sign-on, NMAS'M, or Novell Certificate Server on is set up to be the Security Domain key 
server. 


All subsequent servers that are installed with any of these products contact the Security Domain 
key server during their installation process. Ifthe Security Domain key server cannot be contacted, 
the installation will fail and a message will be displayed indicating that the SAS service object 
could not be created. 


To avoid the SAS service creation error message: 
+ Make sure the Security Domain key server machine is up and running nicisdi.nlm. 


+ Use a common protocol (IP and/or IPX™) between the Security Domain key server and all 
other servers that are installed with Novell Single Sign-on, NMAS, and Novell Certificate 
Server. 


+ Make sure the network connection between the Security Domain key server and the server 
being installed is active. 


You can determine which server is the Security Domain key server by running ConsoleOne?, 
Open the properties page for the WO object. This object is located in the KAP container, which is 
inside the Security Container. Click the Other tab. Click NDSPKI:SD Key Server DN. The value 
displayed is the distinguished name of the Security Domain key server. 


NISP:GET_PDB_PRODUCT:Returned a BTRIEVE error:4 


If you receive this error one or more times during the installation, ignore it and continue with the 
installation. 


Failures During Installation 


If the installation fails during the creation of the Organizational CA or the server certificate, or 
during the exportation of the trusted root certificate, the installation doesn't need to be repeated. 
The software has been successfully installed at this point. You can use ConsoleOne to create an 
Organizational CA and server certificates and export the trusted root. 


Installation Fails with a -1443 Error 
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If a Novell Certificate Server installation fails during installation and you receive a -1443 error 
message, this means that the Security Domain key server and the server that you are installing 
Certificate Server on are not communicating properly. If the server cannot get a copy of the 
Security Domain key, the installation fails. 
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A likely reason is that the server that Certificate Server is being installed to fragments the NCP™ 
extensions, and the fragments are not being reassembled correctly by the Security Domain key 
server. 


One solution to this problem is to increase the MTU of both servers to greater than 576 (the default 
minimum size). 
To increase the MTU on a server: 

1 Type LOAD MONITOR !h from the command line of the server. 

2 Select Server Parameters > click Communications. 


3 Select Maximum Interface MTU > set this value to something higher than 576. 
User Certificate Issues 


Waiting for Servers to Synchronize 


Occasionally, after the user certificate has been created, the client is unable to refresh the view to 
include the new certificate. A dialog box is shown with the message “Waiting for servers to 
synchronize.” At this point, the user certificate has been created but the servers involved in the 
creation have not yet synchronized. You can close the dialog box without impacting the creation 
of the user's certificate. 


Error Reusing Certificate Nicknames 


If an error occurs during user certificate creation, try using a different nickname for the certificate. 
The nickname that was specified might not be available for reuse. 


-1426 Error Exporting a User's Private Key 


All servers with replicas of the partition in which the User object resides should have the same 
level of ervptographv (U.S./Worldwide NICI or Import Restricted NICI). If they do not, an error 
of -1426 may appear when exporting the user's private key if the key size is too large. 


To export the user's private key after a -1426 error has occurred, you must either upgrade the 
cryptography on the servers with replicas of the partition or remove the replica from those servers 
that have exportable cryptography. 


Workstation Cryptography Strength 


If U.S/Worldwide (high-grade) cryptography is loaded on your NetWare server, you will have the 
option to create user certificates with key sizes of 512, 768, 1024, and 2048 bits. However, any 
key size larger than 512 bits cannot be used with GroupWise” 5.5, Outlook 98, Outlook 2000, or 
Netscape Messenger unless you also have high-grade cryptography installed on the client 
workstation. 
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Server Certificate Issues 


External CAS 


Some third-party CAs like Verisign use an intermediate CA to sign server certificates. In order to 
import these certificates into a Server Certificate object, the server certificate as well as the 
Intermediate CA and the trusted root certificate must be in a single PKCS #7 formatted file (.P7B) 
If your CA cannot provide you with such a file, you can create one yourself by following these 
steps on a client machine with Internet Explorer 5.5 or later installed. 


1 Import the server certificate into Internet Explorer. You can do this by double-clicking on the 
file or by selecting File > Open and selecting the filename. 


2 Ifthe external CA's certificate is not already listed as a trusted CA in Internet Explorer, import 
the Intermediate CAs as well as the root level CA in the same manner. 


3 In Internet Explorer, select Tools > Internet Options. Select the Content tab, then select the 
Certificates button. 


4 On the Personal tab, find the server certificate. Select it and click Export. 


5 Accept the defaults in the wizard until you get to the Export File Format page, then select the 
Cryptographic Message Syntax Standard - PKCS #7 Certificates (.p7b) format. 


6 Continue with the wizard. 


The PKCS #7 file can now be imported into the Server Certificate object. 


Moving a Server 


DNS Support 


If a Server object is moved, the LDAP objects, SAS service object, and Server Certificate objects 
(Key Material Objects) for that server must also be moved. 


IfNetWare 5 Support Pack 3 or later is installed and DNS is configured for the server, the default 
subject name for a server certificate will be 


.CN=<Server’s DNS Name>.O=<Tree Name> 


Otherwise, the default subject name is the fully distinguished name of the server. You can modify 
the default subject name by selecting Custom during the certificate creation process. 


NOTE: DNS was not available prior to NetWare 5 Support Pack 3. 


Deletion of the SAS Object 


If you delete the SAS service object, any server certificates previously created for that server 
cannot be used by applications on the server. If these certificates are still needed, you can restore 
the SAS object from backup. If that is not possible, contact Novell Support for assistance. 


Removing a Server from eDirectory 


When removing a server from eDirectory and then reinstalling it into the same context with the 
same name, a successful reinstallation occurs only if the SAS Service object representing the 
removed server is also deleted, if it existed. 
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For example, for a server named MYSERVER, a SAS object named SAS Service - MYSERVER 
could exist in the same container as the server. This SAS object must be manually deleted (using 
ConsoleOne) after the server is removed from the tree, but before the server is reinstalled into the 
tree. 


Ifthe server is the Organizational CA or the SD Key server, you must complete some additional 
steps. These steps are documented in TID #10056795 (http://support.novell.com/cgi-bin/search/ 
searchtid.cgi?/10056795.htm). 


The default server certificates created for the server should also be removed so that they will get 
recreated when the server is reinserted. 


These certificates are SSL Certificate IP - MYSERVER and SSL Certificate DNS - MYSERVER. 
You should be careful when deleting these certificates. If data has been encrypted using either of 
these certificates, the data must be retrieved before the certificates are deleted. 


Step-Up Cryptography, Server-Gated Cryptography, or Global Certificates 


Some external Certificate Authorities provide certificates that enable 40- or 56-bit Web browser 
clients to use 128-bit cryptography when communicating with a server configured with their 
certificates. 


These certificates are sometimes referred to as global certificates or server-gated cryptography 
certificates. The capability can be referred to as step-up cryptography. 


These certificates can be used successfully for LDAP and Web Server connections only if the Web 
browser has 128-bit cryptography. Web browsers with 40- or 56-bit cryptography will experience 
unrecoverable SSL errors when communicating with servers configured with these certificates. 


If Web browsers with 40- or 56-bit cryptography must communicate with your server, you must 
request a different type of certificate from your external CA. 


Subject Name Limitations for CAs 


Server certificates with an @ character in their subject names might cause SSL connections to fail. 
Contact Novell Support for a resolution of the problem. 


ConsoleOne Issues 


ConsoleOne on a Server 


You cannot manage Novell Certificate Server with ConsoleOne running on a server. You must run 
ConsoleOne from a Windows 95/98, Windows 2000, or Windows NT client workstation. 


Refresh After Update 


Occasionally, after you delete a user certificate, the ConsoleOne display does not refresh. To force 
the refresh, close the object view and reopen it. 


Troubleshooting 57 


Organizational CA Issues 


Path Length 


You can enter a maximum value of 255 for the path length of the Organizational CA. Any value 
greater than that will result in an error. 


Moving the Organizational CA Object 


The Organizational CA object must reside in the Security container. 


Validation Issues 


Certificate Validation Speed 
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The certificate validation process includes several checks of the data in the certificate as well as 
the data in the certificate chain. A certificate chain is composed of a Root CA certificate and, 
optionally, the certificates of one or more intermediate CAs. The certificate chain for a certificate 
signed bv vour Organizational CA is composed of one certificate, which is the Organizational 
CA's self-signed certificate. Externally-signed user and server certificates might have longer 
chains. 


Validating the information in a certificate and its associated certificate chain is not a time-intensive 
process. However, there are occasions where the validation might take longer: 


1. If the certificate was signed by an external CA and one or more of the certificates has a CRL 


distribution point extension. 


In order to validate the certificate, the CRL for each applicable certificate in the chain must 
be retrieved. The CRL must then be examined to determine whether or not the certificate has 
been revoked. 


If the CRLs are large or if the server operating the CRL distribution point is busy, it might 
take some time to validate a certificate. The time required can be decreased by doing one or 
more of the following: 


+ Upgrade the speed of the connection being used to check the revocation status of the 
certificate. 


+ Contact your CA provider. 


. If you are validating a user certificate. 


For server certificates, the entire certificate chain is stored along with the server certificate in 
the Kev Material object. Therefore, when a server certificate is validated, the client can get all 
of the certificates necessarv bv simplv reading one object. User certificates, however, are 
stored differentiv. Only the user certificate itself is stored in the User object. Thus, the client 
must retrieve the certificate chain from other objects stored in the Security container in order 
to validate the user certificate. 


In order to validate a user certificate signed by the Organizational CA, the client must read the 
Organizational CA's object in order to retrieve the CA's certificate. In order to validate a user 
certificate signed bv an external CA, the client must read the Trusted Roots container in the 
Securitv container in order to compose a certificate chain that matches the user certificate. In 
the latter case, an Administrator must have alreadv imported the certificates of the external 
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CAs into the Trusted Roots container in order for the validation of the User certificate to 
succeed. 


The time required to validate a user certificate can be decreased by doing one or more of the 
following: 


+ Partition the Security container and widely replicate Read-Only replicas of it. The data in 
the Security container is relatively static, so doing so does not lead to synchronization 
problems within your tree. 


+ Place the replicas of the Security container physically closer to those users who need to 
validate user certificates. 


+ Remove expired certificates that are no longer trusted from the Trusted Roots container. 


Validating Certificates after Deleting the Organizational CA 


If you delete the Organizational CA (other than during a backup and restore procedure), you 
should delete all user and server certificates that were signed by the Organizational CA. If you 
don’t, you will experience the following behavior when validating these certificates: 


+ User certificates signed by the deleted CA will be invalid. This is because the certificate of 


the CA that signed the user certificate could not be found in the Organizational CA object or 
in the Trusted Roots container. If you want those user certificates to remain valid, you must 
add the previous CA's self-signed certificate to the Trusted Roots container. 


Server certificates signed by the deleted CA will continue to be valid. This is because the 
CA's certificate is stored in the Key Material object along with the server certificate. 


If you deleted the Organizational CA because the key had been compromised or because of 
some security breach, you should immediately delete all user and server certificates that were 
signed by the CA. You should also tell all users who may have imported your Organizational 
CA's certificate into their browsers to delete the certificate. 


Miscellaneous Issues 


-1497 Errors 


If you receive a -1497 error while the pki.nlm is loading, or as a result of performing certificate 
management, the probable cause is that NICI has not been installed correctly or has become 
corrupted. 


To resolve the problem, reinstall NICI and retry the operation. If that does not solve the problem, 
call Novell Support. 


Renaming the Security Container 


You cannot rename the security container. 


Certificate Encodings 


UTF8 encoding for subject and issuer names in certificates is not supported. Certificate Server 
cannot issue or use certificates with this type of encoding. 


Although Certificate Server can issue certificates with subject names and issuer names encoded in 
Unicode*, you might encounter problems using them. You might be unable to establish an SSL 
connection using server certificates with Unicode subject or issuer names. 
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Public Key Cryptography Basics 


This sections describes the basics of Public Key Cryptography. 


Overview 


The content of most Internet communications, such as Web page browsing or public chat forums, 
can be monitored by anyone equipped to do so. The content of other data transmissions, such as 
the exchange of credit card information for online purchases, needs to be kept private. 


Public key cryptography is a widely used method for keeping data transmissions private and secure 
on the Internet. Specifically, public key cryptography is the system of using digital codes called 
“keys” to authenticate senders of messages and to encrypt message content. 


Secure Transmissions 


Data transmissions are private and secure when two things happen: 


+ Authentication: The data receiver knows that the data sender is exactly who or what it claims 
to be. 


+ Encryption: The data sent is encrypted so that it can be read only by the intended receiver. 
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Key Pairs 
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Authentication and encryption are both provided through the use of mathematically related pairs 


of digital codes or “keys.” One key in each pair is publicly distributed; the other is kept strictly 
private. 


Each data transmitter, whether a person, a software program, or some other entity such as a bank 
or business, is issued a key pair by a public key cryptography system. 


The basic principles and functions of each key in the key pair are summarized in the following 
illustration. 


Keys in the key pair are generated 
by a cryptography system and used +.., 


in combination only with each other. ° tal 
y Ÿ 
© Public Key 
A cryptography system openly The key pair owner, or a 
publishes this key to any party cryptography system acting on 
needing to validate a signature its behalf, closely guards this 
from a key pair owner or to key. 


encrypt a private 
communication with the key 
pair owner. 


The key pair owner uses 
cryptography-enabled software 


programs and this key to 
Parties requiring private 


HR 5 e Create digital signatures. 
communication with the key $ 8 


pair owner use crvptographv- e Decrvpt data that was 
enabled software programs and encrypted with the key pair 
this key to owner’s public key. 


e Validate signatures of the key 
pair owner. 


e Encrypt data for private 
transmission to the key pair 
owner. 
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Key Pairs and Authentication 


Authentication means that the data receiver knows that the data sender is exactly who or what it 
claims to be. 


Suppose that you want to authorize your bank to transfer funds from your account to another 
account. The bank needs proof that the message came from you and that it has not been altered 
during transit. The following illustrates the process that your online transaction would follow using 


public key cryptography. 
Your Bank 
workstation server 
Transfer request Mi 
and signature 

1. You authorize the transfer 4. Vour bank's computer 
using vour banking receives the request and 
application. vour digital signature. 

2. Vour application creates a 5. A system operator then 
“digital signature” for the validates your signature 
transfer request using your against the request using 
private key (which only your your public key. 
application can access). If the results compute 

3. The application then sends correctly, the signature is 
the request and your digital “authenticated.” 


signature to your bank. If not, the signature, the 


message, or both are assumed 
to be fraudulent, and the 
transaction is denied. 


For information about digital signatures and their verification, see “Digital Signatures” on 
page 65. 
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Key Pairs and Encryption 


Encryption means that the data can be read only by the intended receiver. 


Suppose you want to order a book from an Internet vendor and you need to use your credit card to 
pay for it. You don't want your credit card number read by anyone other than the intended 
recipient. 


The encryption process in the following illustration provides the mechanisms through which your 


credit card number can be safely transmitted. 


Your Bookstore 
workstation server 


Your credit card number 


1. To place your order, you L 5. The bookstore server uses 
enter vour credit card se the bookstore's private key 
number into the bookstore's ka to decrypt the message. 
application. , 


2. The application gets the 
bookstore's public kev 
directlv from the bookstore 
or from a public directorv. 


Others listening on the 

' communications channel 
cannot decrvpt the message 
and see vour card number 
because thev do not have the 
bookstore's private kev. 


3. The application uses this 
kev to encrvpt the message 
containing vour credit card 
number. 


4. The application sends the 
encrvpted message to the 
bookstore server. 


Establishing Trust 


If a sender and receiver know and trust each other, thev can simplv exchange public kevs and 
establish secure data transmission, including authentication and enervption. To do this, thev would 
use each other's public kevs and their own private kevs. 


Under normal circumstances, however, parties needing secure data transmissions have no 
foundation for trusting the identity of each other. Each needs a third party, whom they both trust, 
to provide proof of their identity. 


Certificate Authorities 
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A party needing to prove its identity in a public key cryptography environment enlists the services 
of a trusted third party known as a certificate authority. 


The primary purpose of the certificate authority is to verify that a party is who or what it claims to 
be, and then to issue a public key certificate for that party to use. The public key certificate verifies 
that the public key contained in the certificate belongs to the party named in the certificate. 
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Party needing a certificate sends a 
request to the Certificate Authority 
along with its name, its public key and 
any other information that needs to be 
included in the certificate. 


ts. 
. 
. 


Party requesting 


Certificate Authority verifies Certificate 
certification 


identity of party requesting Authority 
certificate. 


After the identity of the requesting party has been established to the satisfaction of the certificate 


authority, the certificate authority’s issues an electronic “certificate” and applies its digital 
signature. 


Digital Signatures 


Just as a personal signature applied to a paper document indicates the authenticity of the document, 
a digital signature indicates the authenticity of electronic data. 


To create a digital signature, the software used to create the signature links the data being signed 


with the private key of the signer. The following illustration shows the process that a CA follows 
to create its digital signature for a public key certificate. 


rs... Certificate request RER > 


p a... Verification by CA - 
Party requesting Certificate 
certification Authority 


After verification, the Certificate 
Authority does the following: 


1. Creates a public key certificate 
containing the required 
information. 


2. Runs a computation on the 
information in the public key 
certificate to produce a small 


À (usually 16 to 20 bytes) data 
mnt |} string. 


3. Encrypts the small data string 
using its (the CA's) private key. 
te (The encrvpted string is the CA's 


signature for the certificate 
information.) 


4. Sends the public kev certificate 
containing the party's public key 
and the CA's signature to the 


Public Key Cryptography Basics 65 


A digital signature is uniquely linked to the signer and the data. No one else can duplicate the 
signature because no one else has the signer's private key. In addition, the signer cannot deny 
having signed the data. This is known as non-repudiation. 


When a certificate authority signs a public key certificate, it guarantees that it has verified the 
identify of the public key owner according to the certificate authority’s established and published 
policies. 


After signed data (such as a public key certificate) is received, software verifies data authenticity 
by applying the same computation to the data that the signing software used originally. If the data 
is unaltered, both computations produce identical results. It can then be safely assumed that neither 
the data nor the signature was modified in transit. 


Certificate Chain 


Trusted Roots 


A certificate chain is an ordered list of certificates. The certificates are ordered such that the server 
or user certificate is first, followed by the certificate of its CA. 


CAs can either sign their own certificates (that is, they are self-signed) or they can be signed by 
another Certificate Authority. If they are self-signed, they are typically called Root CAs. If they 
are not self-signed, they are typically called subordinate CAs or intermediate CAs. 


If a user or server certificate was signed by a CA with a self-signed certificate, the certificate chain 
is composed of exactly two certificates: the end entity certificate and the root CA. 


If a user or server certificate was signed by an intermediate CA, then the certificate chain is longer. 
The first two elements are still the end entity certificate, followed by the certificate of the 
intermediate CA. But, the intermediate CA's certificate are then followed by the certificate of its 
CA. This listing then continues until the last certificate in the list is for a root CA. Thus, a 
certificate chain can be infinitely long. In practicality, most certificate chains have only two or 
three certificates, though. 


In order to validate a digital signature, you must trust at least one of the certificates in the user or 
server's certificate chain. You can directly trust the certificate of the user or server, or you can 
choose to trust any other certificate in the chain. Typically, the certificate that is trusted is the root 
CA's certificate. 


Most application software that can use certificates already has a list of trusted certificates installed. 
These certificates are for root CAs and, hence, are called "trusted roots." Typically these CAs are 
commercial CAs. If you choose, you can add additional CAs to this list or remove CAs from the 
list. 
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Entry Rights Needed to Perform Tasks 


This list provides the specific entry rights an administrator needs to manage Novell® Certificate 
Server tasks within an eDirectory® tree. These rights are the minimum entry rights needed. 


This list should also be helpful to the administrator who wants to grant rights to another user to 
manage part or all of company’s certificate authority and certificate management needs. 


Tasks 


Install Novell Certificate Server 


Entry Rights Needed 


For the first installation to an NDS® tree: 


+ 


Supervisor at the [Root] of the tree 


For subsequent installations: 


+ 


Supervisor to the WO object 


Creating an Organizational CA 


+ 


Supervisor on the Security container 


Viewing the Organizational CA's properties and 
certificates 


Browse on the Organizational CA's object 


Exporting the Organizational CA's certificate(s) 


+ 


Browse on the Organizational CA's object 


Issuing a public key certificate 


Read to the NDSPKI:Private Key on the 
Organizational CA's object 


Backing up and restoring an Organizational CA 


Supervisor on the Organizational CA's 
object 


Moving the Organizational CA to a different server 


Supervisor on the Organizational CA's 
object 


Validating the Organizational CA's Certificates 


Browse on the Organizational CA's object 


Replacing the Organizational CA 


Supervisor on the Organizational CA's 
object 


Deleting the Organizational CA 


Delete on the Organizational CA's object 


Creating Server Certificate objects 


Supervisor on the server's container 


Read to the attribute NDSPKI:Private Key 
on the Organizational CA's object (only if 
using the Org. CA) 


Importing a public key certificate into a Server 
Certificate object 


Write to the attribute NDSPKI:Public Key 
Certificate on the Server Certificate object 


Write to the attribute NDSPKI:Certificate 
Chain on the Server Certificate Object 
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Tasks 


Entry Rights Needed 


Deleting a Server Certificate object 


+ 


Delete on the Server Certificate object 


Exporting a Trusted Root or Public Key Certificate 
from a Server Certificate object 


+ 


Browse on the Server Certificate object 


Viewing the Server Certificate object's properties 
and certificates 


Browse on the Server Certificate object 


Backing up and restoring a Server Certificate 
object 


Supervisor on the server object that owns 
the Server Certificate object to back-up 


Create on the server object's container to 
restore. 


Validating Server Certificates 


Browse on the Server Certificate object 


Replacing a server certificate's keving material 


Write to the attribute NDSPKI:PrivateKey 
on the server certificate object 


Creating user certificates 


Read to the attribute NDSPKI:Private Key 
on the Organizational CA object 


Read and Write to the attribute 
NDSPKI:userCertificatelnfo on the User 
object 


Read and Write to the attribute 
SAS:SecretStore on the User object 


Read and Write to the attribute 
userCertificate on the User object 


Importing a public key certificate into a User object 


+ 


Read and Write on the attribute 
NDSPKl:userCertificatelnfo on the User 
object 


Read and Write to the attribute 
NDSPKl:userCertificate on the User object 


Viewing a user certificate’s properties 


Browse on the User object 


Exporting a user certificate 


Browse on the User object 


Exporting a user's private key and certificate 


You must be logged in as the user. 


Deleting a user certificate and private key 


Read and Write to 
NDSPKl:userCertificatelnfo 


Read and Write to userCertificate 


Validating User Certificates 


Browse on the User object 


Creating a Trusted Root Container 


Create on the Security container 


Creating a Trusted Root object 


Create on the Trusted Root Container in 
which the Trusted Root object will reside 


Viewing a Trusted Root object’s properties 


Browse on the Trusted Root object 
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Tasks 


Entry Rights Needed 


Replacing a trusted root certificate 


+ 


Read and Write to NDSPKI:Not After on the 
Trusted Root object 


Read and Write to NDSPKI:Not Before on 
the Trusted Root object 


Read and Write to NDSPKI:Subject Name 
on the Trusted Root object 


Read and Write to NDSPKI:Trusted Root 
Certificate on the Trusted Root object 


Validating a trusted root certificate 


Browse on the Trusted Root object 


Deleting a Trusted Root object 


Delete on the Trusted Root object 


Creating a CRL Object 


Create to the container that the 
cRLDistributionPoint object will be created 
in 


Importing a third-party CRL 


Write to the attribute 
certificateRevocationList 


Exporting a third-party CRL 


Read from the attribute 
certificateRevocationList 


Replacing a third-partv CRL 


Browse on the CRL object 


Viewing a third-partv CRL 


Browse to the attribute 
certificateRevocationList 


Creating a Securitv container 


Creating a SAS service object 


Create at the root of the eDirectorv tree 


Supervisor on the object's container 


Write to the attribue SAS:Service DN on the 
server that the object is being created 
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